cmd/compile: better append of unmodified slices

[sylr]

What version of Go are you using (go version)?

$ go version
go version go1.14 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/Users/s.rabot/go/bin"
GOCACHE="/Users/s.rabot/Library/Caches/go-build"
GOENV="/Users/s.rabot/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/s.rabot/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/z0/rcywz4nn3jg6g96h67c_4xzdw31lvl/T/go-build757609694=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

package main

import (
	"testing"
)

func BenchmarkNoCap(b *testing.B) {
	for i := 0; i < b.N; i++ {
		var slice []string

		slice = append(slice, []string{"a", "q", "w"}...)
		slice = append(slice, []string{"z", "s", "x"}...)
	}
}

func BenchmarkCap(b *testing.B) {
	for i := 0; i < b.N; i++ {
		slice := make([]string, 0, 6)

		slice = append(slice, []string{"a", "q", "w"}...)
		slice = append(slice, []string{"z", "s", "x"}...)
	}
}

func BenchmarkCapNoMagicNumber(b *testing.B) {
	for i := 0; i < b.N; i++ {
		base := []string{"a", "q", "w"}
		fixed := []string{"z", "s", "x"}

		slice := make([]string, 0, len(base)+len(fixed))

		slice = append(slice, base...)
		slice = append(slice, fixed...)
	}
}

func BenchmarkCapNoMagicNumberFixedSlices(b *testing.B) {
	for i := 0; i < b.N; i++ {
		base := [...]string{"a", "q", "w"}
		fixed := [...]string{"z", "s", "x"}

		slice := make([]string, 0, len(base)+len(fixed))

		slice = append(slice, base[:]...)
		slice = append(slice, fixed[:]...)
	}
}

What did you expect to see?

I would have expected BenchmarkCapNoMagicNumber and BenchmarkCapNoMagicNumberFixedSlices to have the same throughput.

What did you see instead?

$ go test -bench . -count=3
goos: darwin
goarch: amd64
BenchmarkNoCap-12                          	 7771320	       142 ns/op
BenchmarkNoCap-12                          	 7877163	       142 ns/op
BenchmarkNoCap-12                          	 7857156	       143 ns/op

BenchmarkCap-12                            	59972187	        20.2 ns/op
BenchmarkCap-12                            	58082768	        23.4 ns/op
BenchmarkCap-12                            	44653009	        25.6 ns/op

BenchmarkCapNoMagicNumber-12               	15412473	        74.8 ns/op
BenchmarkCapNoMagicNumber-12               	14540749	        75.1 ns/op
BenchmarkCapNoMagicNumber-12               	15240964	        74.7 ns/op

BenchmarkCapNoMagicNumberFixedSlices-12    	64831053	        21.0 ns/op
BenchmarkCapNoMagicNumberFixedSlices-12    	64266398	        21.4 ns/op
BenchmarkCapNoMagicNumberFixedSlices-12    	60569865	        22.7 ns/op

[bcmills]

@randall77, I think you've got the title backwards. It looks like the sliced array is outperforming the slice-literal version for some reason.

[randall77]

Sorry, yes.

[renthraysk]

Slow routine allocates because len(base)+len(fixed) of slices isn't determined at compile time, whereas with arrays the expression is constant.

[josharian]

Or to be more precise, during the escape analysis phase, len(base)+len(fixed) isn't known to be a constant. (Later on, SSA figures it out.)

[sylr]

So both are optimized to the extent of what they can be or is there room for improvement in the slice case ?

[josharian]

It’s definitely possible for them to be improved. The question—which I can’t answer offhand—is whether it is possible to make a small, local improvement that would cover this case, or whether it would require an overhaul. (There are good independent reasons for an overhaul, but what is needed—eliminating one of the compiler’s intermediate representations—is a huge undertaking.)

[bcmills]

Is this a duplicate of #20533?