cmd/compile: optimize back-to-back append calls

[dsnet]

Go version

go1.25

Output of go env in your module/workspace:

n/a

What did you do?

Consider these two benchmarks:

func BenchmarkA(b *testing.B) {
	for b.Loop() {
		out = out[:0]
		out = append(out, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
	}
}

func BenchmarkB(b *testing.B) {
	for b.Loop() {
		out = out[:0]
		out = append(out, 0)
		out = append(out, 1)
		out = append(out, 2)
		out = append(out, 3)
		out = append(out, 4)
		out = append(out, 5)
		out = append(out, 6)
		out = append(out, 7)
		out = append(out, 8)
		out = append(out, 9)
		out = append(out, 0)
		out = append(out, 1)
		out = append(out, 2)
		out = append(out, 3)
		out = append(out, 4)
		out = append(out, 5)
		out = append(out, 6)
		out = append(out, 7)
		out = append(out, 8)
		out = append(out, 9)
	}
}

What did you see happen?

BenchmarkA
BenchmarkA-32    	1000000000	         0.7381 ns/op
BenchmarkB
BenchmarkB-32    	82785476	        14.66 ns/op

BenchmarkB runs much slower than BenchmarkA.

What did you expect to see?

I would expect these to run about the same speed. The capacity may slighter differ, but I don't think that's guaranteed by append. Furthermore, I suspect the compiler could probably pre-compute what the capacity would have been and preserve identical behavior.

[dsnet]

This might be related to #44628, but that's more about allocations. There are no allocations in my example.
This might be related to #56442, but that's about string concatenation.

[gabyhelp]

Related Issues

• cmd/compile: performance of slice append is optimizable #36405 (closed)
• cmd/compile: combine append calls #25828
• cmd/compile: optimize append performance #14758 (closed)
• cmd/compile: append should be optmized as copy #57759 (closed)
• cmd/compile: treat "d = append(make([]T, 0, len(s)), s...)" as "d = make([]T, len(s)); copy(d, s)" #46079
• cmd/compile: avoid unnecessary allocations for consecutive appends #44628
• cmd/compile: better append of unmodified slices #37694
• runtime: append growth sort of inconsistent and surprising #41239 (closed)
• cmd/compile: performance regression on append-like loop #19633 (closed)
• cmd/compile: optimize slice copy via make+copy #26252 (closed)

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

[thepudds]

The example in #25828 (comment) might be related, which might imply the compiler would need to be smart enough to avoid changing semantics like in that example, including not tripping on aliases.

FWIW, the alias analysis from https://go.dev/cl/710015 is able to report the following slices as unaliased, which might be one piece of establishing the safety of then coalescing them.

func f1() {
        var out []int
        out = append(out, 0)
        out = append(out, 1)
        out = append(out, 2)
        out = append(out, 3)
        out = append(out, 4)
}

./t.go:6:14: alias analysis: append using non-aliased slice: append(out, 0) in func f1
./t.go:7:14: alias analysis: append using non-aliased slice: append(out, 1) in func f1
./t.go:8:14: alias analysis: append using non-aliased slice: append(out, 2) in func f1
[...]