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 > e.g. https://github.com/KDAB/hotspot/issues/115 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 size > 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. Jan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
