<div dir="ltr">Rafael,<div><br></div><div>Your latest benchmark results look great. LLD took 1.38 seconds where gold --threads takes 0.85 seconds. It needs to be faster, but that's not too bad.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 10:13 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="">> Here's an update.<br>
><br>
> After <a href="http://reviews.llvm.org/D8372" target="_blank">http://reviews.llvm.org/D8372</a> , I updated the profiling data.<br>
><br>
> <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>
</span>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?</blockquote><div><br></div><div>Are you suggesting we do linear search instead of hash table lookup each time ArchiveFile::find(StringRef symbolName) is called?</div></div></div></div>