testing: performance regression in TB.Helper in Go 1.12 relative to Go 1.11

[g7r]

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

$ go version
go version go1.11.10 linux/amd64

and

$ go version
go version go1.12.5 linux/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
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/sz/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/sz/go"
GOPROXY=""
GORACE=""
GOROOT="/snap/go/3739"
GOTMPDIR=""
GOTOOLDIR="/snap/go/3739/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build471260994=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Here's the benchmark: https://play.golang.org/p/4PufWKn1Epv

benchstat output:

# benchstat v1.11.10_bench.txt v1.12.5_bench.txt
name       old time/op  new time/op  delta
Helper-12   647ns ± 2%   780ns ± 1%  +20.45%  (p=0.008 n=5+5)

What did you expect to see?

No performance regression.

What did you see instead?

Go 1.12.5 is 20% slower than Go 1.11.10.

[g7r]

git bisect gave me the likely culprit: 69c2c56

[randall77]

It's another ~10% slower at tip :(

I found a simple fix though that actually makes it a bit faster than 1.11. I'll mail it out.
TL;DR we're symbolizing two PCs when we really only need to be symbolizing one.

[gopherbot]

Change https://golang.org/cl/177858 mentions this issue: testing: callerName only needs one PC in the traceback

[cespare]

@g7r is the problem for you specifically with testing.TB.Helper, or was that just the way you chose to demonstrate the regression?

(@randall77's fix in CL 177858 is specifically for Helper.)

[g7r]

@cespare yes, mine problem is specifically with testing.TB.Helper. Its performance heavily affects our test set run duration.

[cespare]

@g7r thanks -- I went ahead and retitled the issue accordingly.

I do wonder whether the underlying regression in runtime.Callers/CallersFrames will show up in other contexts.

[randall77]

There is more we could do here, but it's getting late for big things for 1.13.

[gopherbot]

Change https://golang.org/cl/178077 mentions this issue: runtime: In Frames.Next, delay file/line lookup until just before return