Bloaty McBloatface: a size profiler for binaries
blog.reverberate.org
blog.reverberate.org
$ ~/d/bloaty/bloaty builder/virt-builder -d compileunits
VM SIZE FILE SIZE
-------------- --------------
75.5% 1.96Mi [None] 3.67Mi 85.2%
8.7% 232Ki guestfs-c-actions.c 232Ki 5.3%
8.2% 219Ki guestfs.ml 219Ki 5.0%
2.0% 52.4Ki [Other] 52.4Ki 1.2%
1.3% 33.7Ki _none_ 33.7Ki 0.8%
0.7% 17.5Ki customize_cmdline.ml 17.5Ki 0.4%
0.6% 17.3Ki builder.ml 17.3Ki 0.4%
0.4% 11.8Ki customize_run.ml 11.8Ki 0.3%
0.4% 10.4Ki cmdline.ml 10.4Ki 0.2%
0.3% 7.08Ki firstboot.ml 7.08Ki 0.2%
0.2% 6.21Ki index-scan.c 6.21Ki 0.1%
0.2% 5.90Ki index_parser.ml 5.90Ki 0.1%
0.2% 5.15Ki sigchecker.ml 5.15Ki 0.1%
0.2% 4.87Ki getopt-c.c 4.87Ki 0.1%
[...]Edit: The README mentions this may be caused by incompletely parsed `.debug_aranges'.
bloaty main
VM SIZE FILE SIZE
-------------- --------------
33.0% 536Ki __TEXT,__text 536Ki 33.7%
18.1% 293Ki __TEXT,__gopclntab 293Ki 18.5%
15.6% 253Ki __DWARF,__debug_info 253Ki 16.0%
13.1% 213Ki __TEXT,__rodata 213Ki 13.4%
6.5% 106Ki __DATA,__bss 0 0.0%
0.3% 5.62Ki [None] 93.1Ki 5.9%
4.4% 71.9Ki __DWARF,__debug_frame 71.9Ki 4.5%
4.2% 68.3Ki __DWARF,__debug_line 68.3Ki 4.3%
1.9% 30.5Ki __DWARF,__debug_pubtypes 30.5Ki 1.9%
1.1% 17.1Ki __DATA,__noptrbss 0 0.0%
0.6% 9.90Ki __DWARF,__debug_pubnames 9.90Ki 0.6%
0.6% 9.45Ki __DATA,__noptrdata 9.45Ki 0.6%
0.4% 6.34Ki __DATA,__data 6.34Ki 0.4%
0.2% 2.86Ki __TEXT,__typelink 2.86Ki 0.2%
0.0% 255 __DWARF,__debug_abbrev 255 0.0%
0.0% 72 __TEXT,__itablink 72 0.0%
0.0% 61 __DWARF,__debug_gdb_scri 61 0.0%
0.0% 48 __DWARF,__debug_aranges 48 0.0%
100.0% 1.59Mi TOTAL 1.55Mi 100.0%The first time I remember doing this exercise was when the product I worked on got so large it wouldn't fit on one CD. I think we found 10 copies of one of its shared libraries.
I've written a few hacky exploratory tools for it but nothing of this quality.
I understand if you are working in an environment where both of those could be limited such a tool would be extremely helpful. But I don't think I have ever decided to not use a program because of the size of the executable. I don't spend my day looking at the size of awk vs sed vs grep and then using the one that is smaller.
I'd rather send or receive a 3MB file instead of a 14MB.
Also think of smartphones. People often complain about app sizes, because they often just have 16 or 32 GB.
I do agree that in resource constrained environments it is good to examine what it taking up space, but the exe may not be the first place to look, especially for image heavy smartphone apps.
Assuming "spare" terrabytes of disk and gigabytes of ram breaks down at Google/Amazon/Facebook/etc scale.
(I've bookmarked this, because I'm trying to work out how to fit enough of OpenCV into the spare resources on a STM32 microcontroller to be useful... I doubt the author will be too concerned about bugs/doco for _my_ use case though...)
Is that the average size savings?
But that is at .o file granularity. There's no per-symbol dead code elimination.
And if you provide a list of .o files (no .a files) then it doesn't throw away anything at all.
But besides annoyance to customers, remember that bandwidth costs are quite large for popular products. Something like a browser or MS Office update is going to get downloaded billions of times.
This is also a reason behind moving from a ball mud to microservices (nee SOA).
(The solution was to make sure string deduplication was on in the linker.)