<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 18, 2016 at 11:47 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15 January 2016 at 18:05, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> On Thu, Jan 14, 2016 at 7:25 AM, Rafael Espíndola<br>
> <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>><br>
>> > In total, this patch improves link time of lld itself about 12%<br>
>> > (3.50 seconds -> 3.08 seconds.)<br>
>><br>
>> That is quite slow, is in a debug build that you are linking? What is<br>
>> the size of the string table if you use discard_locals? I wonder if we<br>
>> are keeping more symbols than gold or bfd.<br>
><br>
><br>
> That is a debug build. I haven't tried discard_locals yet,<br>
<br>
</span>Using a no-asserts build of lld to link a Release+Asserts build of lld<br>
with all arches, what I got was:<br>
<br>
r257017:<br>
* strtab is 3916859 bytes<br>
* link takes 0.317558552 seconds<br>
<br>
r257016:<br>
* strtab is 3812950 bytes (1.027* smaller)<br>
* link takes 0.353217270 seconds (1.11* slower)<br>
<br>
r257016 with StrTabBuilder.finalize commented out as a timing hack.<br>
* link time is 0.331792363 (1.04X slower)<br>
<br>
Which is strange, so I got about 3% instead of 0.3% but about the same<br>
slowdown. The link itself is about 10X faster than what you reported.<br></blockquote><div><br></div><div>I wanted to write is that lld executable size (not the string table size) is 0.3% smaller. Sorry for the confusing mistake.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>> Have you tried just not calling StrTabBuilder.finalize() similar to<br>
>> what we do for SHF_STRINGS sections when not optimizing? That way we<br>
>> would have fast linking at -O0 and smaller tables at -O2.<br>
><br>
><br>
> and neither StrTabBuilder.finalize(). But I don't want to use<br>
> StrTabBuilder.finalize() because the API has the problem as I described in<br>
> this patch. Look for "Why two phases?" and read the comment. Also, I think<br>
> StringTableBuilder is slower than this implementation even if we don't call<br>
> finalize() because StringTableBuilder copies strings, while this<br>
> implementation does not (it keeps only StringRefs).<br>
<br>
</span>Any implementation that removes duplicated strings will have to be a<br>
bit more expensive. The question is if it is still noticeable when not<br>
tail merging. Given that the timing with the hack was still doing<br>
unnecessary hash lookups, I would say we should at least revisit this.<br>
I will open a bug to track it.<br></blockquote><div><br></div><div>What's the string table size when you disabled tail merging but did de-duplication?</div></div></div></div>