gcc 了解编译时间在哪里答案

【问题标题】：gcc understand where compilation time is takengcc 了解编译时间在哪里
【发布时间】：2012-07-05 11:46:04
【问题描述】：

我有一个大量使用模板的项目。最近编译时间突然增加了。我想知道是否有办法查看哪些类/行需要最多时间才能由 g++ 编译。

这是 -ftime-report 的一些输出

Execution times (seconds)
 TOTAL                 :   0.30             0.05             0.37               9119 kB

Execution times (seconds)
 garbage collection    :   0.91 ( 6%) usr   0.00 ( 0%) sys   0.92 ( 5%) wall       0 kB ( 0%) ggc
 callgraph construction:   0.23 ( 2%) usr   0.11 ( 3%) sys   0.37 ( 2%) wall   10652 kB ( 1%) ggc
 callgraph optimization:   0.18 ( 1%) usr   0.12 ( 3%) sys   0.28 ( 2%) wall   11906 kB ( 2%) ggc
 varpool construction  :   0.04 ( 0%) usr   0.01 ( 0%) sys   0.08 ( 0%) wall    6984 kB ( 1%) ggc
 cfg construction      :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall     644 kB ( 0%) ggc
 cfg cleanup           :   0.05 ( 0%) usr   0.02 ( 0%) sys   0.05 ( 0%) wall       7 kB ( 0%) ggc
 trivially dead code   :   0.05 ( 0%) usr   0.01 ( 0%) sys   0.12 ( 1%) wall       0 kB ( 0%) ggc
 df scan insns         :   0.37 ( 3%) usr   0.03 ( 1%) sys   0.43 ( 2%) wall     677 kB ( 0%) ggc
 df live regs          :   0.07 ( 0%) usr   0.01 ( 0%) sys   0.02 ( 0%) wall       0 kB ( 0%) ggc
 df reg dead/unused notes:   0.08 ( 1%) usr   0.01 ( 0%) sys   0.08 ( 0%) wall    2755 kB ( 0%) ggc
 register information  :   0.05 ( 0%) usr   0.01 ( 0%) sys   0.05 ( 0%) wall       0 kB ( 0%) ggc
 alias analysis        :   0.01 ( 0%) usr   0.01 ( 0%) sys   0.01 ( 0%) wall     878 kB ( 0%) ggc
 rebuild jump labels   :   0.03 ( 0%) usr   0.01 ( 0%) sys   0.01 ( 0%) wall       0 kB ( 0%) ggc
 preprocessing         :   0.19 ( 1%) usr   0.44 (11%) sys   0.68 ( 4%) wall    5284 kB ( 1%) ggc
 parser                :   3.94 (28%) usr   1.43 (35%) sys   4.94 (27%) wall  355964 kB (48%) ggc
 name lookup           :   1.35 ( 9%) usr   0.88 (21%) sys   2.76 (15%) wall   64919 kB ( 9%) ggc
 inline heuristics     :   0.14 ( 1%) usr   0.03 ( 1%) sys   0.14 ( 1%) wall       0 kB ( 0%) ggc
 integration           :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall      20 kB ( 0%) ggc
 tree gimplify         :   0.31 ( 2%) usr   0.07 ( 2%) sys   0.28 ( 2%) wall   24598 kB ( 3%) ggc
 tree eh               :   0.07 ( 0%) usr   0.02 ( 0%) sys   0.11 ( 1%) wall    7267 kB ( 1%) ggc
 tree CFG construction :   0.04 ( 0%) usr   0.04 ( 1%) sys   0.11 ( 1%) wall   15754 kB ( 2%) ggc
 tree CFG cleanup      :   0.12 ( 1%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall       3 kB ( 0%) ggc
 tree find ref. vars   :   0.03 ( 0%) usr   0.01 ( 0%) sys   0.02 ( 0%) wall     963 kB ( 0%) ggc
 tree PHI insertion    :   0.00 ( 0%) usr   0.01 ( 0%) sys   0.01 ( 0%) wall     351 kB ( 0%) ggc
 tree SSA rewrite      :   0.03 ( 0%) usr   0.01 ( 0%) sys   0.01 ( 0%) wall    4078 kB ( 1%) ggc
 tree SSA other        :   0.03 ( 0%) usr   0.06 ( 1%) sys   0.12 ( 1%) wall    1504 kB ( 0%) ggc
 tree operand scan     :   0.04 ( 0%) usr   0.02 ( 0%) sys   0.08 ( 0%) wall   10781 kB ( 1%) ggc
 dominance computation :   0.15 ( 1%) usr   0.04 ( 1%) sys   0.15 ( 1%) wall       0 kB ( 0%) ggc
 out of ssa            :   0.09 ( 1%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall       0 kB ( 0%) ggc
 expand vars           :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall    1840 kB ( 0%) ggc
 expand                :   0.45 ( 3%) usr   0.04 ( 1%) sys   0.59 ( 3%) wall   37695 kB ( 5%) ggc
 post expand cleanups  :   0.08 ( 1%) usr   0.02 ( 0%) sys   0.06 ( 0%) wall    4542 kB ( 1%) ggc
 varconst              :   0.15 ( 1%) usr   0.03 ( 1%) sys   0.12 ( 1%) wall    3595 kB ( 0%) ggc
 jump                  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall    1904 kB ( 0%) ggc
 mode switching        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall       0 kB ( 0%) ggc
 integrated RA         :   1.33 ( 9%) usr   0.09 ( 2%) sys   1.49 ( 8%) wall   18163 kB ( 2%) ggc
 reload                :   0.60 ( 4%) usr   0.10 ( 2%) sys   0.62 ( 3%) wall    8668 kB ( 1%) ggc
 thread pro- & epilogue:   0.17 ( 1%) usr   0.00 ( 0%) sys   0.20 ( 1%) wall   11884 kB ( 2%) ggc
 reg stack             :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall       0 kB ( 0%) ggc
 final                 :   0.71 ( 5%) usr   0.10 ( 2%) sys   0.84 ( 5%) wall    6251 kB ( 1%) ggc
 symout                :   1.10 ( 8%) usr   0.16 ( 4%) sys   1.19 ( 6%) wall  100954 kB (14%) ggc
 uninit var analysis   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall       0 kB ( 0%) ggc
 early local passes    :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall       0 kB ( 0%) ggc
 rest of compilation   :   0.49 ( 3%) usr   0.06 ( 1%) sys   0.76 ( 4%) wall   19252 kB ( 3%) ggc
 unaccounted todo      :   0.43 ( 3%) usr   0.09 ( 2%) sys   0.55 ( 3%) wall       0 kB ( 0%) ggc
 TOTAL                 :  14.26             4.11            18.52             742072 kB

【问题讨论】：

您需要提供比这更多的信息。没有任何东西可看，我们很难提供帮助。
你可以尝试编译不同的版本，看看什么时候出现时间增加；然后查看该修订版中发生的变化，希望能给您一些见解。
可能值得看看这个线程stackoverflow.com/questions/2072454/…
Debugging GCC Compile Times的可能重复

标签： c++ templates gcc g++

【解决方案1】：

Steven Watanabe 模板分析器可以帮助您获得每个类/函数的实例化计数。有关此工具的实际链接，请参阅 Debugging GCC Compile Times。

【讨论】：

现在，还可以使用更好的 clang 9 -ftime-trace 选项

【解决方案2】：

当我看到您在项目中大量使用模板时，我首先怀疑是模板实例化，看到以下信息后，我的怀疑更加强烈：

parser       : ... (27%) wall 355964 kB (48%) ggc
name lookup  : ... (15%) wall 64919 kB ( 9%) ggc

由于我看不到代码（因为您没有发布它），所以我只能怀疑。我的第二个怀疑是，您没有使用 known 类型的模板的 explicit 实例化（您肯定会使用），而是依赖于 implicit 实例化并且您正在使用来自大量.cpp 文件的模板。如果是这样，那么这可能是主要问题，因为 implicit 实例化会导致 same 模板被实例化多次次，每个翻译单元一次。因此，如果您有 M 模板并且您从 N 翻译单元 (.cpp) 使用它，那么将有 M * N 实例化，而不仅仅是 M 实例化。

【讨论】：

非常感谢。就是这种情况，在许多 .cpp 文件中实例化了相同的模板类。我会尝试找出需要最多时间的模板类，并对其进行修改。

【解决方案3】：

AFAIK，不存在这样的编译开关。

一种更手动的方法是在预处理和编译之间分开（gcc -E，然后在预处理文件上使用gcc -c）来猜测时间花在哪里。

另一个解决方案是检测您的构建环境以使每个文件都有编译时间。请注意，我只能建议设置持续集成以尽早跟踪此类演变（一旦弹出，您就可以检测到它，而无需挖掘过去是什么引入了跳跃）。

根据经验，您可以检查是否只包含相关的标头（尝试删除一些），或者可以切换到预编译的标头，

【讨论】：

非常感谢。我已经对编译时间最长的文件有所了解。而且，正如您所指出的，这些文件包含大多数标题。我尝试使用预编译的头文件，但没有得到更高的速度改进（我仍然不明白为什么）。只有 ccache 给了我速度提升
和 -Q 我知道大部分时间都花在了解析器上。但我不知道这对于可疑的代码意味着什么。
-ftime-report 选项存在于 Mac OS X 上，/usr/bin/gcc -- i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)。更全面的报告似乎来自/usr/bin/clang——Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn)。它可能是clang 的一个选项，也可能只是最新版本的 GCC 中的一个选项。
谢谢，-ftime-report 存在于 g++ 中，但它提供了您在帖子中看到的内容