search for: archivefiles

Rafael, 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. 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. > > >

...ed a 404 but nothing about it in the rails log. It doesn''t happen every time, 9 out of 10 times it works just fine. The post (is actually a put) comes from a .NET application uploading a small xml-file. The log message in apache looks like this [21/Nov/2007:15:56:15 +0100] "POST /archivefiles/173688 HTTP/1.1" 404 - .. and the vhost <VirtualHost *:8080> #Fix for Apache bug 39499 SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1 XSendFile on XSendFileAllowAbove on RewriteEngine On # Check for maintenance file. Let apache load it if...

Okay, I understood that you're proposing to add all undefined symbols during the resolution step, and not try to collect extra symbols during execution and then check if some undefines left (as I originally planned). This sounds reasonable as in any case we must have all undefines resolved in order to continue the linking process. Concerning the implementation, why not to add this virtual

On Thu, Feb 19, 2015 at 10:40 PM, Denis Protivensky <dprotivensky at accesssoftek.com> wrote: > Shankar, > > Okay, I guessed the correct interface. > But what about the moment at which the function is called? > If it's called from Resolver::resolve(), it doesn't make any difference to > me as I cannot determine the need of specific symbols at that time. > > -

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 > >> >

On Mon, Mar 16, 2015 at 1:54 AM, Davide Italiano <davide at freebsd.org> wrote: > > Shankar's parallel for per-se didn't introduce any performance 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

I spent a week to optimize LLD performance and just wanted to share things what I found. Also if there's anyone who have a good idea on how to make it faster, I'd like to hear. My focus is mainly on Windows, but my optimizations are generally platform neutral. I aim both single-thread and multi-thread performance. r231434 <http://reviews.llvm.org/rL231454> is a change that has the