Comping a project (with -j48), it took real 18m47.06s user 42m7.06s sys 11h58m9.18s I tried to ld_preload realpath to make it always return 0. Then it became real 2m17.11s user 30m18.90s sys 49m24.01s With below code, #include <iostream> #include <algorithm> int main() { return 0; } If you check the strace output, you will find it has way more lstat call in gcc48 build than the gcc47 one, especially if you have some header file in /some/very/very/deep/folder/to/include. Can it canonicalise the path when it needs to report the error? This may be the culprit: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974 Code change is here: http://gcc.gnu.org/bugzilla/attachment.cgi?id=27160&action=diff
No, that is definitely not possible, the paths are what is stored during preprocessing etc. I see two options (but I'm really surprised by the above numbers, what kind of filesystem is it on, some slow networked filesystem, otherwise I can't believe the few canonicalizations would be so costly), either we'd just canonicalize the include system directory names, which would give different behavior if the header filename in the directory was a symlink, but still would deal with the something/../../../whatever/else/ paths in the common case, or we'd canonicalize the system header directory names and then for each component being added as filename (i.e. whatever is in #include directive) we'd just lstat those components separately, in the common case where none of those is a symlink, we'd then just not call lrealpath on the whole dirname+filename, otherwise we would.