internal/maps: performance regression in MapFirst, MapLast etc in 1.27rc2 vs 1.26.5

[archanaravindar]

Go version

go1.27rc2, also in the master

Output of go env in your module/workspace:

GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN='/home/archanaravindar/Go/Go_master/go/bin'
GOCACHE='/home/archanaravindar/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/archanaravindar/.config/go/env'
GOEXE=''
GOEXPERIMENT='nodwarf5'
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3127455941=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/archanaravindar/Downloads/perfdash/go-test-work/go1.27rc2/src/go.mod'
GOMODCACHE='/home/archanaravindar/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/archanaravindar/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/golang'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/archanaravindar/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/lib/golang/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.25.12 X:nodwarf5'

What did you do?

Ran MapFirst, MapLast tests in go1.26.5 and go1.27rc2

What did you see happen?

Benchmark performance is slower in go1.27rc2 compared to go1.26.5
│ mapfirstallold.out │ ../../../go1.27rc2/src/runtime/mapfirstallnew.out │
│ sec/op │ sec/op vs base │
MapFirst/1-8 2.218n ± 2% 3.218n ± 1% +45.12% (p=0.000 n=10)
MapFirst/2-8 2.290n ± 4% 3.306n ± 3% +44.36% (p=0.000 n=10)
MapFirst/3-8 2.265n ± 5% 3.354n ± 2% +48.08% (p=0.000 n=10)
MapFirst/4-8 2.327n ± 2% 3.410n ± 3% +46.54% (p=0.000 n=10)
MapFirst/5-8 2.410n ± 5% 3.457n ± 3% +43.42% (p=0.000 n=10)
MapFirst/6-8 2.385n ± 5% 3.419n ± 4% +43.32% (p=0.000 n=10)
MapFirst/7-8 2.434n ± 6% 3.586n ± 5% +47.30% (p=0.000 n=10)
MapFirst/8-8 2.470n ± 3% 3.530n ± 3% +42.91% (p=0.000 n=10)
MapFirst/9-8 5.015n ± 8% 5.792n ± 4% +15.48% (p=0.000 n=10)
MapFirst/10-8 5.020n ± 7% 5.688n ± 3% +13.32% (p=0.000 n=10)
MapFirst/11-8 5.143n ± 4% 5.814n ± 4% +13.04% (p=0.000 n=10)
MapFirst/12-8 5.145n ± 4% 5.769n ± 4% +12.12% (p=0.000 n=10)
MapFirst/13-8 5.071n ± 6% 5.949n ± 6% +17.33% (p=0.000 n=10)
MapFirst/14-8 5.228n ± 5% 5.619n ± 7% +7.48% (p=0.000 n=10)
MapFirst/15-8 5.009n ± 2% 5.874n ± 4% +17.27% (p=0.000 n=10)
MapFirst/16-8 5.072n ± 4% 5.831n ± 4% +14.95% (p=0.000 n=10)
geomean 3.457n 4.443n +28.53%

What did you expect to see?

Performance should have been on par on both releases
this not only affects amd64 but other platforms such as ppc64le

[archanaravindar]

CL 736020 (2026-01-13) https://go-review.googlesource.com/c/go/+/736020 optimized mapaccess1 and mapaccess2 by converting mapaccess1 to a thin wrapper and retaining the body of mapaccess2 as the code of both functions were almost identical. In the process it changed both the compiler (emit mapaccess2 directly) and the runtime (mapaccess1 becomes a thin wrapper) to implement this.
However eventually this caused a compiler crash in cases where mapaccess2 could not be used as a subexpression (for ex
from inside a switch or a comparison)
hence the change was reverted by CL 793000 https://go-review.googlesource.com/c/go/+/793000 however only the compiler part was reverted restoring mapaccess1 calls (emitting
mapaccess1 instead of mapaccess2)
but the wrapper still remains. so now as a result mapaccess1 is emitted which is a wrapper around mapaccess2, so both get
called and looks like the inlining dynamics does not allow either to be inlined so both functions figure in the top 3 hot functions.
It appears that restoring the full bodies of mapaccess1 and mapaccess2 as before would be the right solution. Perhaps
there is a better solution?

go1.26.5
flat flat% sum% cum cum%
1.59s 36.72% 36.72% 3.01s 69.52% runtime.mapaccess1_fast64
1.27s 29.33% 66.05% 4.28s 98.85% runtime_test.BenchmarkMapFirst.func1
0.67s 15.47% 81.52% 0.67s 15.47% internal/runtime/maps.ctrlGroup.matchFull (inline)

go1.27rc2
flat flat% sum% cum cum%
1520ms 33.41% 33.41% 2470ms 54.29% runtime.mapaccess2_fast64
1390ms 30.55% 63.96% 4550ms 100% runtime_test.BenchmarkMapFirst.func1
690ms 15.16% 79.12% 3160ms 69.45% runtime.mapaccess1_fast64

[gabyhelp]

Related Issues

• internal/runtime/maps: hash copy of key instead of key itself makes map run slowly #76083 (closed)
• runtime: map clear in go 1.25 performance pitfalls #75097 (closed)
• runtime: performance regression for small Swiss Table map access for non-specialized keys #70849 (closed)
• strings: performance regression in strings/CountHard* benchmarks #80638

Related Code Changes

• runtime: evacuate old map buckets more consistently
• internal/runtime/maps/: devirtualize hashing for specialized maps
• runtime: exit early when scanning map buckets
• runtime: add mapdelete_fast*
• internal/runtime/maps: rewrite MemHash{32,64} using simd/archsimd intrinsics
• runtime: vectorized map bucket lookup

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

[randall77]

Yeah, we should fix this somehow. It will need to wait for 1.28 though, it is too risky for 1.27 at this point.