On 10/4/20 2:48 PM, Jan Kratochvil wrote: > 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. I'm not sure it's that marginal. It may not matter for GDB since I don't think the bottleneck is likely the decompression. It would certainly matter for profiling and the like -- I'd probably argue that dwarf is a terrible choice for those tools, but I don't see CTF as a viable alternative though, so they're stuck in the dwarf world. > > 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. Please, let's stop talking about btrfs here. It's not useful. However, I think it's perfectly valid to discuss zstd if folks wanted to change the compression scheme for debug sections. In fact, I'd claim sticking with zlib, gzip, bzip2, xz, 7z, etc is unwise. The world has moved and zstd seems like the place we should be. In fact, we use it for various things within GCC already. Jeff
Attachment:
pEpkey.asc
Description: application/pgp-keys
_______________________________________________ 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
