<div dir="ltr">*nod* It might be possible to (maybe too low-level - not sure if zlib exposes this, or if the format even allows it to be efficiently answered) retrieve the size of a compressed section without decompressing it (at least in zlib-gnu fromat, I think the uncompressed size is written before the compressed data, so easy there) - that way maybe more things wouldn't need to care about whether it was compressed or not - it could be decompressed lazily (& then the other half would be to deallocate promptly, as soon as those bytes were finished with/written out to the output and no longer needed).<br><br>At some point, it'd be even great to use streaming compression in and out. (I guess you could probably even use streaming decompression for the pubnames - so even a whole object file's pubnames wouldn't need to be decompressed simultaneously - just ask for the next chunk of decompressed data, process it, then overwrite it with the next chunk, etc).</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 17, 2018 at 4:08 PM Rui Ueyama via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ruiu added a comment.<br>
<br>
It is doable and perhaps we should do that. Currently, we decompress all compressed sections before doing anything, so that such sections are handled as if they weren't compressed at all, but sometimes that leads to a waste of time and memory.<br>
<br>
<br>
Repository:<br>
  rLLD LLVM Linker<br>
<br>
<a href="https://reviews.llvm.org/D52126" rel="noreferrer" target="_blank">https://reviews.llvm.org/D52126</a><br>
<br>
<br>
<br>
</blockquote></div>