[llvm-commits] [PATCH] Make Path::GetMainExecutable faster on OSX

Nick Kledzik kledzik at apple.com
Tue Sep 8 15:14:50 PDT 2009


On Sep 8, 2009, at 3:05 PM, Daniel Dunbar wrote:

> On Tue, Sep 8, 2009 at 3:02 PM, Chris Lattner<clattner at apple.com>  
> wrote:
>>
>> On Sep 8, 2009, at 2:58 PM, Daniel Dunbar wrote:
>>
>>> Wow, nice catch -- I've known something was wrong because of the
>>> amount of system time it consumes, but hadn't dug in. This makes  
>>> your
>>> patch an even bigger win w/ more threads, its almost 50% faster for
>>> me.
>>>
>>> Looking at the code now I'm wondering if it is even right that
>>> clang-cc uses the main executable path to resolve headers. I think
>>> this change got made to accommodate symlinked binaries, but I'm not
>>> sure that "GetMainExecutablePath" is really the right way to find
>>> this. Chris?
>>
>> I don't really know either.  Nick, do you have an opinion about this?
>
> The question of how to resolve headers is different from
> GetMainExecutable (which I think we should fix).
>
> I think we should probably resolve headers by taking the realpath of
> the abspath of the argv[0], but I'm not sure if there was a good
> reason we didn't do this. I think it was because you decided readlink
> was evil. :)
Well, if the command line to invoke the compiler was just "clang" and  
the clang binary was found by the shell by searching $PATH, then argv  
will be just "clang", so calling realpath() won't help.  To solve this  
problem on Mac OS X, the kernel passes dyld the executable path used  
in the exec(), and dyld makes that path available via  
_NSGetExecutablePath().

How often is GetMainExecutable() called?  If a lot (which it sounds  
like if no calling dladdr() is that much better), then perhaps,  
GetMainExecutable( should cache the result?

-Nick


>
>
> - Daniel
>
>>> On Tue, Sep 8, 2009 at 11:52 AM, Benjamin
>>> Kramer<benny.kra at googlemail.com> wrote:
>>>>
>>>> Playing around with shark shows that much of the startup time of  
>>>> clang-cc
>>>> is
>>>> spent in dladdr looking for the executable path. There is another  
>>>> dyld
>>>> API
>>>> called _NSGetExecutablePath which does the same thing much  
>>>> faster. The
>>>> function is available since 10.2 and documented in "man 3  
>>>> dyld" (I don't
>>>> know why it has a leading underscore though).
>>>>
>>>> benchmark: clang testsuite on my 2007 macbook pro (debug build,  
>>>> best of 3
>>>> runs)
>>>>
>>>> dladdr:
>>>> --- Running clang tests for i686-apple-darwin10.0.0 ---
>>>> Testing Time: 57.76s
>>>>
>>>> _NSGetExecutablePath:
>>>> --- Running clang tests for i686-apple-darwin10.0.0 ---
>>>> Testing Time: 48.71s
>>>>
>>>>
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>
>>>>
>>
>>




More information about the llvm-commits mailing list