Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux