On Tue, 29 Sep 2020 22:29:44 +0200, Mark Wielaard wrote:
I was just discussing that recently with the Hotspot Perf GUI
maintainer. And we concluded that if .debug files would be compressed
then we would need an uncompressed cache somewhere. The issue with
having the on-disk debuginfo files compressed is that for
debugger/tracing/profiling tools it incurs an significant
decompression time delay and extra memory usage. Especially for a
profiling tool that only needs to quickly get a little information it
is much more convenient to be able to simply mmap the .debug file,
check the aranges and directly jump to the correct DIE offset. See
First is is a marginal use case. For the GDB popular here I tested zlib on
some IIRC 500MB+ .debug file and the startup time was 11.00s->12.45s
= +13.20%. Given GDB takes minutes to print something on such .debug files the
<2s larger startup does not matter.
And then all this is about zlib compression. Facebook has developed zstd which
is much faster. Google says faster than reading the .debug files, on my
machine both zstd and NVMe disk read are both 2GB/s. I expect btrfs has even
in-memory cache for decompressed files but I have not checked it now as all
the numbers I have collected have no effect here anyway.
Because I believe it is the most important benchmark. The on-disk
is not just the installed file size, but it is also the in memory size
of the data structures that need to be stored and parsed. So a 20%
smaller on-disk size also (roughly) means 20% less DIEs and abbrevs
that need to be parsed or held into memory.
The problem is that you have to wait for minutes for GDB to print anything.
It is faster to add cout<<, recompile and rerun the program (with clang+lld as
with g++ it takes more than 3x as much time) than to wait for GDB. LLDB would
sure print it immediately but it is incompatible with Fedora DWARF. Enjoy.