[LLVMdev] On LLD performance

Rui Ueyama ruiu at google.com
Fri Mar 20 15:02:20 PDT 2015


On Fri, Mar 20, 2015 at 2:56 PM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> >> > https://people.freebsd.org/~davide/llvm/lld-03162015.svg
> >> > It seems now 85% of CPU time is spent inside
> >> > FileArchive::buildTableOfContents().
> >> > In particular, 35% of the samples are spent inserting into
> >> > unordered_map, so there's maybe something we can do differently there
> >> > (e.g. , Rui's proposal of a concurrent map doesn't seem that bad).
> >> >
> >>
> >> Why do we even need to build the table from name to member?
> >>
> >> Can't we just walk "archive->symbols()" and check for each symbol if
> >> it is needed by the current link status?
> >
> >
> > Are you suggesting we do linear search instead of hash table lookup each
> > time ArchiveFile::find(StringRef symbolName) is called?
>
>
> No, what I mean is that we only need to keep one hash of the current
> state of the link (which symbols are still undefined).
>
> Once you get to an archive, don't build a hashtable of every symbol it
> provides. Instead, walk the list of symbols it provides and if one of
> those is currently undefined in the global table, include it in the
> link.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150320/329e9f03/attachment.html>


More information about the llvm-dev mailing list