<div dir="ltr"><div>Here is the results of linking clang (with debug info) with various compression levels. Apparently, the current compression level 9 seems overkill.</div><div><br></div><div><font face="monospace, monospace">Level   Time            Size</font></div><div><font face="monospace, monospace">0       0m17.128s       2045081496   Z_NO_COMPRESSION</font></div><div><font face="monospace, monospace">1       0m31.471s       922618584    Z_BEST_SPEED</font></div><div><font face="monospace, monospace">2       0m32.659s       903642376</font></div><div><font face="monospace, monospace">3       0m36.749s       890805856</font></div><div><font face="monospace, monospace">4       0m41.532s       876697184</font></div><div><font face="monospace, monospace">5       0m48.383s       862778576</font></div><div><font face="monospace, monospace">6       1m3.176s        855251640    Z_DEFAULT_COMPRESSION</font></div><div><font face="monospace, monospace">7       1m15.335s       853755920</font></div><div><font face="monospace, monospace">8       2m0.561s        852497560</font></div><div><font face="monospace, monospace">9       2m33.972s       852397408    Z_BEST_COMPRESSION</font></div><font face="monospace, monospace"><br></font><div class="gmail_quote"><div dir="ltr">On Thu, Aug 2, 2018 at 3:09 AM Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't claim to be an expert, but I did some zlib compression<br>
benchmarks in the past. IIRC, my conclusion from that was that the<br>
"DEFAULT" zlib level (6) is indeed a very good default for a lot of<br>
cases -- it does not generate much larger outputs, while being<br>
significantly faster than the max level. This all depends on the data<br>
set and what you intend to do with the resulting data, of course, but<br>
I guess my point is you don't have to choose only between 1 and 9. I<br>
think it would be interesting to at least get the data for the default<br>
level before making choice.<br>
<br>
cheers,<br>
pl<br>
On Thu, 2 Aug 2018 at 01:57, Rui Ueyama via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Folks,<br>
><br>
> I'd like to get expert's opinion on which compression level is suitable for lld's -compress-debug-section=zlib option, which let the linker compress .debug_* sections using zlib.<br>
><br>
> Currently, lld uses compression level 9 which produces the smallest output in exchange for a longer link time. My question is, is this what people actually want? We didn't consciously choose compression level 9. That was just the default compression level for zlib::compress function.<br>
><br>
> For an experiment, I created a patch to use compression level 1 instead of 9 and linked clang using that modified lld. By default, lld takes 1m4s to link clang with --compress-debug-sections=zlib. With that patch, it took only 31s.<br>
><br>
> Here is a comparison of clang executable size with various configurations:<br>
><br>
> no debug sections:    275 MB<br>
> level 9 compression:  855 MB<br>
> level 1 compression:  922 MB<br>
> no compression:      2044 MB<br>
><br>
> Given that the best compression takes significantly longer time than the fastest compression, we probably should change the default to level 1. Any objections?<br>
><br>
> I wonder what is the best compression level when -O2 is passed to lld. We could use level 9 when -O2 is passed, but is there any reason to compress debug sections that hard in the first place?<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>