जीसीसी समझता है कि संकलन समय कहाँ लिया जाता है

Question

मेरे पास एक प्रोजेक्ट है जो टेम्पलेट्स का भारी उपयोग करता है। हाल ही में संकलन समय काफी अचानक बढ़ गया। मुझे आश्चर्य है कि क्या देखने के लिए कोई तरीका है कि कक्षाओं/रेखाओं को जी ++ द्वारा संकलित करने के लिए सबसे अधिक समय की आवश्यकता होती है।

यहाँ -ftime-रिपोर्ट

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 

Answer 1

स्टीवन वाटानाबे टेम्पलेट प्रोफाइलर आपको प्रति वर्ग/फ़ंक्शन इंस्टेंसेशन गणना प्राप्त करने में सहायता कर सकता है। इस उपकरण के वास्तविक लिंक के लिए Debugging GCC Compile Times देखें।

Answer 2

AFAIK से कुछ उत्पादन होता है, ऐसी कोई संकलन स्विच मौजूद है।

प्रीप्रोसेसिंग और संकलन (, फिर gcc -c प्रीप्रोसेस्ड फाइल पर) के बीच विभाजित करने के लिए एक और मैन्युअल विधि को विभाजित किया जा सकता है यह अनुमान लगाने के लिए कि समय कहाँ बिताया जाता है।

एक और समाधान आपके निर्माण पर्यावरण को प्रति फ़ाइल संकलन समय के लिए उपकरण बनाना है। ध्यान दें कि मैं केवल ऐसे विकास को ट्रैक करने के लिए निरंतर एकीकरण स्थापित करने की सिफारिश कर सकता हूं (जैसे ही यह पॉप अप हो जाए, आप इसे अतीत में खोदने के बिना इसका पता लगाएंगे)।

एक सामान्य नियम के रूप में, आप देख सकते हैं कि केवल प्रासंगिक हेडर शामिल किए गए हैं (कुछ दूर करने की कोशिश) या precompiled हेडर के लिए स्विच कर सकता है,

Answer 3

जब मैंने पढ़ा है कि आप अपनी परियोजना में टेम्पलेट्स में से बड़े पैमाने पर इस्तेमाल किया है , मेरा पहला संदेह टेम्पलेट इन्स्टेन्शियशन था, और निम्न जानकारी को देखने के बाद, मेरे संदेह बन मजबूत:

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

जब से मैं कोड नहीं देख सकते हैं (जैसा कि आप इसे पोस्ट नहीं किया है), इसलिए मैं केवल शक कर सकते हैं। मेरी दूसरी संदेह यह है कि आप जाना जाता प्रकार (जो आप सबसे निश्चित रूप से उपयोग किया जाएगा) के लिए टेम्पलेट्स के स्पष्ट इन्स्टेन्शियशन उपयोग नहीं किया है, बजाय आप पर निहित इन्स्टेन्शियशन निर्भर करते हैं और आप .cpp के बहुत से टेम्पलेट का उपयोग कर रहे हैं फ़ाइल। यदि ऐसा है, तो यह बड़ी समस्या हो सकती है, क्योंकि निहित तत्कालता उसी टेम्पलेट्स को प्रत्येक अनुवाद इकाई के लिए कई बार तत्काल होने का कारण बनता है। तो यदि आपके पास M टेम्पलेट्स हैं और आप इसे N अनुवाद इकाइयों (.cpp) से उपयोग कर रहे हैं, तो M इंस्टॉलेशन के बजाय M * N तत्कालियां होंगी।