all: understand binary size changes vs 1.14 #38694
Description
I was curious about binary size changes from 1.14 to tip. The results:
file before after Δ %
addr2line 4307728 4415680 +107952 +2.506%
api 5972696 5256224 -716472 -11.996%
asm 5134472 5098312 -36160 -0.704%
buildid 2843720 2901096 +57376 +2.018%
cgo 4823736 4843608 +19872 +0.412%
compile 24899576 19983664 -4915912 -19.743%
cover 5259800 5292392 +32592 +0.620%
dist 3665080 3718888 +53808 +1.468%
doc 4672712 4071904 -600808 -12.858%
fix 3372856 3422024 +49168 +1.458%
link 6613720 6755112 +141392 +2.138%
nm 4253280 4373520 +120240 +2.827%
objdump 4655376 4763232 +107856 +2.317%
pack 2294280 2364760 +70480 +3.072%
pprof 14747604 14618708 -128896 -0.874%
test2json 2819320 2889496 +70176 +2.489%
trace 11669292 11783892 +114600 +0.982%
vet 8342376 7231080 -1111296 -13.321%
total 120347624 113783592 -6564032 -5.454%
This immediately raises a few questions.
- Why are a few tools significant smaller? (cmd/compile shrank mostly because of the rulegen changes at the beginning of the cycle. I don't understand cmd/doc, cmd/vet, and cmd/api.)
- Why are most tools a bit larger? Did a core package (like runtime) grow considerably? Was it due to compiler regressions? Something about the new linker?
There may not be any bugs here, but it'd be nice to understand a bit better what happened.
Anybody up for doing some sleuthing?
Of note for anyone investigating, you'll discover that object files are ~50% bigger at tip than 1.14. This is due to the -newobj flag being enabled by default. If you're going to use object files to investigate, you probably want to disable it.