[ccache] [patch] Massive performance degradation with direct mode due to bypassing filesystem cache with mmap (Mac/PPC)

[Christian Lohmaier]

Hi Joel, *;

On Wed, Aug 25, 2010 at 10:24 PM, Joel Rosdahl <joel at rosdahl.net> wrote:
> On 2010-08-23 13:35, Christian Lohmaier wrote:
>> [...] Using mmap [on Mac/PPC] to load all the include files bypasses
>> the filesystem cache [...]
>
> Ouch. That surprises me. Thanks for telling!

You're welcome :-))

> [...]
>> * is there any reason why you don't use calloc but use malloc + memset?
>
> I guess you mean in manifest.c? No, no special reason. Changed. Thanks!

Thanks a lot.

>> * [ccache-skip bug]
>
> That's funny, I just noticed and fixed that bug three days ago! I didn't
> know of the patch. I haven't scanned old mailing list posts for patches;
> maybe I should.

For me, that bug was the only one that needed patches, I only had
another one for objective-c(++) files (but that was added already) -
but of course checking the archives surely doesn't hurt.

>> Also I noticed that ccache now reject everything remotely looking like
>> a filelist, this is a little unfortunate since OOo uses -install_name
>> @_(50 underscores)identifier/libraryname to later rewrite it to the
>> target location and thus those compiles won't be cached - hashing
>> install_name and its value should be OK....
>
> I don't quite follow you. What do you mean by "reject"?

reject in this case means: doesn't even attempt to cache it.
random pick from ccache-log:
Compiler option
@__________________________________________________OOO/libaggmxi.dylib
is unsupported
Failed; falling back to running the real compiler
Executing /usr/bin/g++-4.0 -Wl,-multiply_defined,suppress -lobjc
-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -install_name
@__________________________________________________OOO/libaggmxi.dylib
-dynamiclib -single_module -L../unxmacxi.pro/lib
-L/Volumes/zfstest/cloph/botwork/shadow/solver/300/unxmacxi.pro/lib
-L/usr/lib -o ../unxmacxi.pro/lib/libaggmxi.dylib -lpthread -lstdc++
-lm -filelist ../unxmacxi.pro/misc/libaggmxi.list

Looking at it again, I realize that you can ignore most/all of that,
since it is used when linking, and ccache doesn't cache linking
anyway.

So it boils down to bad statistics (unsupported compiler option
instead of called for link), and not "doesn't cache stuff it could
cache".

Adding -install_name to the set of options that require an argument
should do the trick, then the @____ argument will not trigger the "is
too hard" case.

Maybe even add -isysroot to that list, since that otherwise triggers
"/Developer/SDKs/MacOSX10.4u.sdk is not a regular file, not
considering as input file" in the log.
But that (opposed to the linker one) would be merely cosmetics (would
save a stat call)

Nevertheless some background info:
Locating libraries on Mac is different from how it is done on linux
for example. On Mac the linker doesn't search in a set of configured
directories, but all libraries have direct references to the target
libraries, the only exception are the special variables
@executable_path and @loader_path and @rpath
(see http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html
at the very bottom - "Dynamic Library Loading")

OOo uses the @_____… placeholders to later rewrite those paths to the
final location, depending where each lib actually ends in the final
product, and third-party stuff included in OOo also make use of
@executable_path (e.g icu)

ciao
Christian