all: binary size regression

[prattmic]

The performance dashboard shows pretty significant regressions in binary size across most (all?) binary size benchmarks. Look for the "total-bytes" graphs. Regressions vary from around +2% to +30%.

A specific example shows that the regression occurred between 647870b and 814e72f.

Full log: https://go.googlesource.com/go/+log/647870becc230b022b431a4ef8b7c9b31382db6c..814e72f2ef280da54d1af8088b9a732fda9f217b

814e72f go/types, types2: don't panic converting a constant to aliased type parameter
816b603 go/types, types2: add missing Unalias calls (clarification)
7164fad net/http: disable flaky 100-continue tests
5a9dabc cmd/compile: for rangefunc, add checks and tests, fix panic interactions
6438658 cmd/compile: Fix SSA building bug for CAS atomics on ARM64
1a349fc unsafe: document the behavior of Sizeof on an interface
180ea45 runtime/coverage: remove uses of //go:linkname

cc @golang/compiler

[prattmic]

Looks like the cause is 180ea45 / https://go.dev/cl/585820.

$ go test -c gonum.org/v1/gonum/graph/community

community.test is 4616661 bytes at 647870b and 5377941 bytes at 180ea45 (+16%).

These binary size benchmarks all happen to be test binaries. I'm guessing the new internal/coverage/cfile test dependency is bigger than expected.

Since this is only test binaries, it seems a bit less concerning. Still, it is surprising that what is theoretically "just" a refactor has such a big binary size impact.

cc @rsc @thanm @cherrymui

[cherrymui]

My guess is that previously the coverage stuff is only built if coverage is enabled. Now it is always built, just disabled if -cover is not set.

[thanm]

I have some ideas on how to fix this, I'll look into it this morning.

[gopherbot]

Change https://go.dev/cl/587795 mentions this issue: cmd/go,testdeps: move import of internal/coverage/cfile to testmain