Bug 1049609
| Summary: | [RFE] GCC48 calling realpath slow down the compilation significantly | ||
|---|---|---|---|
| Product: | Red Hat Developer Toolset | Reporter: | Bryan Totty <btotty> |
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | Martin Cermak <mcermak> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | DTS 2.0 RHEL 6 | CC: | drieden, law, mcermak, mfranc, mnewsome, mpolacek |
| Target Milestone: | --- | Keywords: | FutureFeature, Performance |
| Target Release: | 3.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-11 10:56:44 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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