search for: archivefil

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

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

...the > atoms. > > This gives a single place where linker defined atoms are actually > created, and allows correct deadstripping and object file references > without doing multiple resolver passes. As Rui showed, we already have this abstraction. The linking context just adds a magic ArchiveFile. When queried for any “linker defined symbol”, the magic ArchiveFile instantiates the atoms needed. This is how mach-o handles linker defined symbols like __dso_handle. -Nick > >> >> >> On 02/19/2015 08:15 PM, Shankar Easwaran wrote: >> >> + Nick >> >...

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

...e 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 t...

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

...singly small delay when linking large binaries, probably thanks to parallel file loading and archive member preloading. Or just that file parsing is an easy task. Preloading hit rate is >99%, so when you need a symbol from an archive file, its member is almost always parsed and ready to be used. ArchiveFile::find() returns immediately with a result. Writers and other post-resolver passes seem reasonably fast. The dominant factor is the resolver. What the resolver does is, roughly speaking, reading files until it resolves all symbols, and put all symbols received from files to a hash table. That'...