[lld] r257017 - ELF: Improve performance of string table construction.
Rafael EspĂndola via llvm-commits
llvm-commits at lists.llvm.org
Mon Jan 18 11:47:19 PST 2016
On 15 January 2016 at 18:05, Rui Ueyama <ruiu at google.com> wrote:
> On Thu, Jan 14, 2016 at 7:25 AM, Rafael EspĂndola
> <rafael.espindola at gmail.com> wrote:
>>
>> > In total, this patch improves link time of lld itself about 12%
>> > (3.50 seconds -> 3.08 seconds.)
>>
>> That is quite slow, is in a debug build that you are linking? What is
>> the size of the string table if you use discard_locals? I wonder if we
>> are keeping more symbols than gold or bfd.
>
>
> That is a debug build. I haven't tried discard_locals yet,
Using a no-asserts build of lld to link a Release+Asserts build of lld
with all arches, what I got was:
r257017:
* strtab is 3916859 bytes
* link takes 0.317558552 seconds
r257016:
* strtab is 3812950 bytes (1.027* smaller)
* link takes 0.353217270 seconds (1.11* slower)
r257016 with StrTabBuilder.finalize commented out as a timing hack.
* link time is 0.331792363 (1.04X slower)
Which is strange, so I got about 3% instead of 0.3% but about the same
slowdown. The link itself is about 10X faster than what you reported.
>> Have you tried just not calling StrTabBuilder.finalize() similar to
>> what we do for SHF_STRINGS sections when not optimizing? That way we
>> would have fast linking at -O0 and smaller tables at -O2.
>
>
> and neither StrTabBuilder.finalize(). But I don't want to use
> StrTabBuilder.finalize() because the API has the problem as I described in
> this patch. Look for "Why two phases?" and read the comment. Also, I think
> StringTableBuilder is slower than this implementation even if we don't call
> finalize() because StringTableBuilder copies strings, while this
> implementation does not (it keeps only StringRefs).
Any implementation that removes duplicated strings will have to be a
bit more expensive. The question is if it is still noticeable when not
tail merging. Given that the timing with the hack was still doing
unnecessary hash lookups, I would say we should at least revisit this.
I will open a bug to track it.
Cheers,
Rafael
More information about the llvm-commits
mailing list