5 ms·
I do have to point out that this visualization represents the binary executable size of Chrome, not the source tree. (According to another comment, it's generat
by mtigas 16y ago
I do have to point out that this visualization represents the binary executable size of Chrome, not the source tree. (According to another comment, it's generated with http://github.com/martine/bloat http://github.com/martine/bloat .)
Noticed a lot of folks linking to directory treesize visualizations.
This — breaking down a compiled binary to show the size of it’s constituent components — is a ton more interesting to me.
- Lerc 16y ago...and yet it includes header files. curious. Looking at what's there, it looks like it can compile and run C (in nativeclient?).
- caf 16y agoIt's possible to define symbols in header files (for example, inline functions).
- _delirium 16y agoI thought the way the C preprocessor worked, those ended up getting literally copy and pasted into the .c file that #include'd them, and should be indistinguishable from the case where you wrote them directly in the .c file? Or does gcc keep track of where #include'd files came from, and write that info into the binary?
- parbo 16y agoYes, otherwise you'd never find syntax errors in the header files.
- scott_s 16y agoBut that's during the compilation phase - this is the compiled binary. Binaries that are compiled with debugging information turned on will include this information for a similar reason: so that when you're debugging a program, or when it breaks, you can map that to places in your source file.
- caf 16y agoRight - and `nm` uses the debugging information to identify the file:line where each symbol was defined. The original scripts used to generate the treemap use `nm`.
- illumen 16y agoyes, and no. Whole program optimization kinda changes that. So do precompiled headers etc. Also chrome is C++.
- mfukar 16y agoCould be precompiled headers, inline functions, etc.