<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 21 October 2016 at 21:29, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Oct 21, 2016, at 12:13 PM, Gábor Horváth <<a href="mailto:xazax.hun@gmail.com" target="_blank">xazax.hun@gmail.com</a>> wrote:</div><br class="m_-2028069354318965550Apple-interchange-newline"><div><div dir="ltr">Hi!<br><div><div class="gmail_extra"><br><div class="gmail_quote">On 20 October 2016 at 18:12, Mehdi Amini via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On Oct 20, 2016, at 2:23 AM, Ilya Palachev via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> It seems that compressing AST files with simple "gzip --fast" makes them 30-40% smaller.<br>
> So the questions are:<br>
> 1. Is current AST serialization format really non-compressed (only abbreviations in bit stream format)?<br>
> 2. Is it worthwhile to compress AST by default (with -emit-ast)?<br>
> 3. Will this break things like PCH?<br>
> 4. What's the current trade-off between PCH compile time and disk usage? If AST compression makes compilation a bit slower, but reduces the disk usage significantly, will this be appropriate for users or not?<br>
<br>
</span>Is there a need for this disk usage? If the main use of AST files is C++ modules / PCH, what is a typical size for a module cache directory?<br>
(Compression is expensive)<br></blockquote><div><br><br></div><div>In some cases compression can actually improve the peformance, because in some cases the bottleneck is the I/O, and less data read from the disk and a fast decompression can be beneficial to the overall performance. </div></div></div></div></div></div></blockquote><div><br></div></span><div>Are you speculating or do you have numbers on the actual AST writer/reader?</div><div><br></div><div>Also a good starting point would be to consider not storing the AST as “blob” in the bitcode but using proper abbrev.</div></div></div></blockquote><div><br><br></div><div>I do not have any numbers for this use case, but as far as I remember there were some benchmarks for some executable packers like UPX that can reduce the startup time of some applications in some cases.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><div><br></div><blockquote type="cite"><div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>In case someone wants to do a whole project analysis on merged ASTs, this compression can be a very significant saving. Dumping all of LLVM and Clang TUs to the disk occupies about 45 GB of disk space at the moment.<br></div></div></div></div></div></div></blockquote><div><br></div></span><div>Sure, adding a compression layer on top for this particular application seems interesting, but you don’t need to have it on *by default* to support your use case though. </div><div>Having it always-on would require as a starting point to look closely at the impact on memory/time when including modules for example.</div><span class=""><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
—<br>
Mehdi<br>
<div class="m_-2028069354318965550HOEnZb"><div class="m_-2028069354318965550h5"><br>
<br>
><br>
> LLVM already has a support for compression (functions compress/uncompress in include/llvm/Support/Compressi<wbr>on.h).<br>
><br>
> Best regards,<br>
> Ilya Palachev<br>
> ______________________________<wbr>_________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div></div>
</div></blockquote></span></div><br></div></blockquote></div><br></div></div>