<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 20, 2015 at 2:56 PM, 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>>> > <a href="https://people.freebsd.org/~davide/llvm/lld-03162015.svg" target="_blank">https://people.freebsd.org/~davide/llvm/lld-03162015.svg</a><br>
>> > It seems now 85% of CPU time is spent inside<br>
>> > FileArchive::buildTableOfContents().<br>
>> > In particular, 35% of the samples are spent inserting into<br>
>> > unordered_map, so there's maybe something we can do differently there<br>
>> > (e.g. , Rui's proposal of a concurrent map doesn't seem that bad).<br>
>> ><br>
>><br>
>> Why do we even need to build the table from name to member?<br>
>><br>
>> Can't we just walk "archive->symbols()" and check for each symbol if<br>
>> it is needed by the current link status?<br>
><br>
><br>
> Are you suggesting we do linear search instead of hash table lookup each<br>
> time ArchiveFile::find(StringRef symbolName) is called?<br>
<br>
<br>
</span>No, what I mean is that we only need to keep one hash of the current<br>
state of the link (which symbols are still undefined).<br>
<br>
Once you get to an archive, don't build a hashtable of every symbol it<br>
provides. Instead, walk the list of symbols it provides and if one of<br>
those is currently undefined in the global table, include it in the<br>
link.<br></blockquote><div> </div><div>I think that wouldn't work. When we find a member file in an archive that resolves an undefined symbol, the file would add both undefined and defined symbols. We would need to scan the list of symbols again.</div></div></div></div>