search for: d8372

...benefit > (or regression). > If the change I propose is safe, I would like to see Shankar's change > in (and this on top of it). > I have 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...

...would like to see Shankar's change >> > in (and this on top of it). >> > I have 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,...

Currently, member functions like File::defined() return an iterator for const atoms. But we don't actually treat atoms as consts -- we updates atoms in many places including the core resolver. We have too many const_casts in our code. It just doesn't make sense. I'm making a change to make atoms non-const. Please hit reply if you have any concerns. -------------- next part

...eat. LLD took 1.38 seconds where gold --threads takes 0.85 seconds. It needs to be faster, but that's not too bad. On Thu, Mar 19, 2015 at 10:13 AM, Rafael Espíndola < rafael.espindola 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...

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