On 17 Oct 2019, Richard Biener verbalised: > On Thu, Oct 17, 2019 at 7:36 PM Nick Alcock <nick.alc...@oracle.com> wrote: >> >> On 11 Oct 2019, Indu Bhagat stated: >> > Compile with -g -gdwarf-like-ctf and use dwz -o <binary_dwz> <binary> >> > (using >> > dwz compiled from the master branch) on the generated binaries: >> > >> > (coreutils-0.22) >> > .debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf >> > (uncompressed) | ratio (.ctf/(D1+D2+0.5*D4)) >> > ls 30616 | 1136 | 21098 | 26240 >> > | 0.62 >> > pwd 10734 | 788 | 10433 | 13929 >> > | 0.83 >> > groups 10706 | 811 | 10249 | 13378 >> > | 0.80 >> > >> > (emacs-26.3) >> > .debug_info(D1) | .debug_abbrev(D2) | .debug_str(D4) | .ctf >> > (uncompressed) | ratio (.ctf/(D1+D2+0.5*D4)) >> > emacs-26.3.1 674657 | 6402 | 273963 | 273910 >> > | 0.33 > > Btw, for a fair comparison you have to remove all DW_TAG_subroutine > children as well since CTF doesn't represent scopes or local variables > at all (nor types only used by locals). It seems CTF only represents > function entry points.
Good point: I'll have to hack up a DWARF trimmer to do this comparison properly, I think. (Though CTF does represent global variables, including file-scope statics.) In most cases local types etc are a fairly small contributor to the total volume -- but macros can contribute a lot in some codebases. (The Linux kernel's READ_ONCE macro is one I've personally been bitten by in the past, with a new local struct in every use. GCC doesn't deduplicate any of those so the resulting bloat from tens of thousands of instances of this identical structure is quite incredible...)
