cmd/compile: poor escape analysis of `strings.SplitSeq`

[tdakkota]

Go version

go version go1.24.2 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/tdakkota/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/tdakkota/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build509906469=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/tmp/example/go.mod'
GOMODCACHE='/home/tdakkota/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/tdakkota/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/tdakkota/.go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='on'
GOTELEMETRYDIR='/home/tdakkota/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/tdakkota/.go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.2'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

https://go.dev/play/p/ug9pN6sRb5M

What did you see happen?

Parameters, result and #state1 leak to the heap.

$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: example.com/module
cpu: AMD Ryzen 9 5950X 16-Core Processor
BenchmarkRowContainsSeq-32      14006036                83.51 ns/op           72 B/op          4 allocs/op
PASS
ok      example.com/module      1.173s
$ go test -gcflags='-m=1' -v ./
# example.com/module [example.com/module.test]
./m_test.go:14:2: can inline RowContainsSeq-range1
./m_test.go:23:2: skip inlining within testing.B.loop for for loop
./m_test.go:14:33: inlining call to strings.SplitSeq
./m_test.go:14:33: inlining call to strings.splitSeq
./m_test.go:14:33: inlining call to strings.explodeSeq
./m_test.go:23:12: inlining call to testing.(*B).Loop
./m_test.go:13:21: leaking param: haystack
./m_test.go:13:31: leaking param: needle
./m_test.go:14:6: r does not escape
/home/tdakkota/.go/src/strings/iter.go:37:14: yield does not escape
/home/tdakkota/.go/src/strings/iter.go:54:14: yield does not escape
./m_test.go:13:47: moved to heap: result
moved to heap: #next
./m_test.go:14:2: moved to heap: #state1
./m_test.go:14:2: func literal escapes to heap
./m_test.go:14:33: func literal does not escape
./m_test.go:14:33: func literal does not escape
./m_test.go:22:30: leaking param: b
... 

tip (at f9ce1dd) is slightly better:

$ go version
go version devel go1.25-f9ce1dddc2 Sat Apr 26 08:01:54 2025 -0700 linux/amd64
$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: example.com/module
cpu: AMD Ryzen 9 5950X 16-Core Processor
BenchmarkRowContainsSeq-32      15135822                77.55 ns/op           72 B/op          3 allocs/op
PASS
ok      example.com/module      1.177s

What did you expect to see?

No allocations at all.
Callback version (https://go.dev/play/p/IRc-1K3qP6M) of this code yields better results:

$ go test -bench=RowContainsCallback -benchmem
goos: linux
goarch: amd64
pkg: example.com/module
cpu: AMD Ryzen 9 5950X 16-Core Processor
BenchmarkRowContainsCallback-32         48458893                25.23 ns/op            0 B/op          0 allocs/op
PASS
ok      example.com/module      1.225s

[tdakkota]

A simple patch equalizes performance with callback version, though:

Patch

diff --git a/src/strings/iter.go b/src/strings/iter.go
--- a/src/strings/iter.go
+++ b/src/strings/iter.go
@@ -32,25 +32,24 @@ func Lines(s string) iter.Seq[string] {
 }
 
 // explodeSeq returns an iterator over the runes in s.
-func explodeSeq(s string) iter.Seq[string] {
-	return func(yield func(string) bool) {
-		for len(s) > 0 {
-			_, size := utf8.DecodeRuneInString(s)
-			if !yield(s[:size]) {
-				return
-			}
-			s = s[size:]
+func explodeSeq(s string, yield func(string) bool) {
+	for len(s) > 0 {
+		_, size := utf8.DecodeRuneInString(s)
+		if !yield(s[:size]) {
+			return
 		}
+		s = s[size:]
 	}
 }
 
 // splitSeq is SplitSeq or SplitAfterSeq, configured by how many
 // bytes of sep to include in the results (none or all).
 func splitSeq(s, sep string, sepSave int) iter.Seq[string] {
-	if len(sep) == 0 {
-		return explodeSeq(s)
-	}
 	return func(yield func(string) bool) {
+		if len(sep) == 0 {
+			explodeSeq(s, yield)
+			return
+		}
 		for {
 			i := Index(s, sep)
 			if i < 0 {

$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: example.com/module
cpu: AMD Ryzen 9 5950X 16-Core Processor
BenchmarkRowContainsSeq-32      52767405                22.72 ns/op            0 B/op          0 allocs/op
PASS
ok      example.com/module      1.202s

[gabyhelp]

Related Issues

• cmd/compile: escape analysis on closures #39511 (closed)
• cmd/compile: unexplained allocation for convT2I #15451
• cmd/compile: ranging exclusively values over slices and arrays that are not cheaply indexable keeps alive 3 registers instead of 2 #61629 (closed)
• Go escape analysis doesn't report variable escape with slice append #45148 (closed)
• cmd/compile: stringtoslicebytetmp optimization on unescaped slice #38501 (closed)
• cmd/compile: support inlining of functions containing function literals #28727 (closed)
• cmd/compile: escape analysis report mismatch with allocations #36083 (closed)
• runtime: Benchmarking reports unexpected memory allocation when using range with map structure #37757
• cmd/compile: escape analysis does't treat reflect header correctly #39497 (closed)

Related Code Changes

• cmd/gc: allocate buffers for non-escaped strings on stack

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[Jorropo]

Good catch, do you want to send a CL ? At first glance I don't see why the compiler couldn't compile the previous one without the heap but your patch is a simple quick win.

[adonovan]

I don't see why the compiler couldn't compile the previous one without the heap

An even smaller patch to avoid the (apparent) escape is to observe that s is never loaded/stored outside the closure, so the closure can use a distinct variable initialized to copy of the parameter instead, like so:

func explodeSeq(s string) iter.Seq[string] {
	return func(yield func(string) bool) {
+		s := s
		for len(s) > 0 {

A smarter compiler could make this change automatically.

I'm not yet convinced the (apparent) escape of s is actually the problem though. When explodeSeq is considered in isolation, its s parameter must escape because it is updated by the function closure. In other words, the escape of the result implies the escape of s. But considering functions in isolation may be pessimistic, as in this example, where f's parameter x must escape (for the same reason as above), but when f is actually called from main, the closure clearly doesn't escape, so there's no need for x to escape either:

func f(x int) any {  // <---- x appears to escape
	return func() int { x++; return x }
}
func main() {
	println(f(1).(func() int)()) // <--- yet this is compiled without allocating
}

In other words, escape analysis is synergistic with inlining, so the escape that the compiler reports for a source function might be more pessimistic than what you get when you actually call it. I suspect that may be happening in your case (but I haven't checked yet). If so, the slowdown of the iterator version may be because range-over-func always allocates a heap variable to hold the continuation state.