我有一个大量使用模板的项目。最近编译时间突然上升。我想知道是否有办法看到哪些类/行需要最多的时间来编译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
答案 0 :(得分:8)
Steven Watanabe模板分析器可以帮助您获得每类/功能的实例计数。 有关此工具的实际链接,请参阅Debugging GCC Compile Times。
答案 1 :(得分:4)
当我读到您在项目中大量使用模板时,我的第一个怀疑是模板实例化,在看到以下信息后,我的怀疑变得更加强烈:
parser : ... (27%) wall 355964 kB (48%) ggc
name lookup : ... (15%) wall 64919 kB ( 9%) ggc
由于我看不到代码(因为你还没有发布),所以我只能怀疑。我的第二个怀疑是,你没有使用显式实例化已知类型的模板(你肯定会使用它们),而是依赖于隐式< / em> instantiation 和您正在使用来自大量.cpp
文件的模板。如果是这样,那么这可能是主要问题,因为隐式实例化导致相同的模板被实例化许多次,每个翻译单元一次。因此,如果您拥有M
个模板并且您使用的是N
个翻译单元(.cpp
),则会有M * N
个实例化,而不仅仅是M
实例
答案 2 :(得分:0)
AFAIK,确实没有这样的编译开关。
更加手动的方法可以在预处理和编译(gcc -E
,然后在预处理文件上gcc -c
)之间进行划分,以猜测花费的时间。
另一种解决方案是检测构建环境以获得每个文件的编译时间。请注意,我只能建议设置持续集成以尽早跟踪此类演变(只要它弹出,您可以检测到它而无需过去挖掘引入跳转的内容)。
根据经验,您可以检查是否只包含相关标头(尝试删除一些标头)或者可以切换到预编译标头,