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

Daniel Dunbar daniel at zuster.org
Tue Sep 8 16:51:44 PDT 2009


On Tue, Sep 8, 2009 at 3:14 PM, Nick Kledzik<kledzik at apple.com> wrote:
>
> 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().

In practice clang-cc is called by the driver, so I'm not sure how
robust this particular mechanism needs to be to arbitrary input.

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

Only once, but note this was just about running on our test suite
(which runs clang-cc a lot). :)

 - 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