Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all: understand binary size changes vs 1.14 #38694

Open
josharian opened this issue Apr 27, 2020 · 3 comments
Open

all: understand binary size changes vs 1.14 #38694

josharian opened this issue Apr 27, 2020 · 3 comments

Comments

@josharian
Copy link
Contributor

@josharian josharian commented Apr 27, 2020

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.

@josharian josharian added this to the Go1.15 milestone Apr 27, 2020
@thanm
Copy link
Member

@thanm thanm commented Apr 27, 2020

Just to be clear, when you list this line:

link 6613720 6755112 +141392 +2.138%

This is comparing 1.15 linker sources built with 1.15 toolchain, vs 1.14 sources built with 1.14 toolchain, correct?

I spent a little time looking at the specific case of the linker. From objdump -h it looks as though the size increase is spread out across many sections (text, pclntab, dwarf, etc) as opposed to being just in one or two sections.

@josharian
Copy link
Contributor Author

@josharian josharian commented Apr 27, 2020

@thanm yes, exactly.

@josharian
Copy link
Contributor Author

@josharian josharian commented Apr 27, 2020

@thanm probably worth doing the experiment of compiling the 1.14 tools with the 1.15 toolchain and vice versa. If you do that, please report the results back here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.