search for: buildtableofcontents

...other related changes coming next, but I would like to tackle > them one at a time. > Here's an update. After http://reviews.llvm.org/D8372 , I updated the profiling data. 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). Thanks, -- Davide "There are no solved problems; there are only problems that a...

...at gmail.com> wrote: > > Here's an update. > > > > After http://reviews.llvm.org/D8372 , I updated the profiling data. > > > > 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...

...a time. >> > >> >> Here's an update. >> >> After http://reviews.llvm.org/D8372 , I updated the profiling data. >> >> 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). > > > Anyone tried a DenseMap instead of an unordere...

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). > >> > > >&gt...

On Sat, Mar 14, 2015 at 2:52 AM, Nick Kledzik <kledzik at apple.com> wrote: > Rui, > > Thanks for this write up and the work you are doing to improve performance. > A couple of thoughts: > > * In the old days, linking was I/O bound so the linker run tended to be the > same speed as cat’ing all the input files together. Now that spinning disks > are less common, I/O