जीसीसी बिल्ड समय प्रीकंपील्ड हेडर से अधिक लाभ नहीं देता

Question

मेरे पास एक बड़ी परियोजना है, सी ++ कोड के लगभग 150 000 एलओसी। समय बनाना लगभग 15 मिनट है। इस परियोजना में विभिन्न आकारों की कई उप-परियोजनाएं शामिल हैं।

मैंने प्रत्येक सबप्रोजेक्ट के लिए अलग प्रीकंपिल्ड हेडर बनाए हैं, लेकिन जब मैं उनका उपयोग करता हूं तो निर्माण समय लगभग वही रहता है। ऐसा लगता है कि निर्माण का समय 5-10% कम है, और अधिक नहीं।

Precompiled हेडर निश्चित रूप से प्रयोग किया जाता है मैं -Winvalid-pch विकल्प का उपयोग और मैं -H संकलक विकल्प के साथ संकलन करने की कोशिश की है, मेरे precompiled हेडर 'बैंग' प्रतीक, इसका मतलब है कि संकलक precompiled शीर्ष लेख का उपयोग करने में सक्षम है के साथ उत्पादन में दिखाई देता है।

मेरे सभी प्रीकंपील्ड हेडर बहुत बड़े नहीं हैं, प्रत्येक फ़ाइल लगभग 50 एमबी है। मैं पाइथन लिपि का उपयोग करता हूं, here पाया जाता है ताकि अधिकांश प्रयुक्त प्रीकंपील्ड हेडर की सूची उत्पन्न हो सके, इसलिए प्रीकंपिलेशन उम्मीदवारों की मेरी सूची काफी अच्छी है।

क्या निर्माण अनुकूलन के लिए कोई खाली/मुक्त स्रोत उपकरण है? ऐसा लगता है कि मानक make उपयोगिता में विभिन्न लक्ष्यों के निर्माण के समय को मापने की क्षमता नहीं है। मुझे make के साथ विभिन्न लक्ष्यों के आंकड़े प्राप्त करने का तरीका नहीं मिल रहा है। मैं निर्भरता विश्लेषण या कुछ उन्नत के बारे में बात नहीं कर रहा हूँ। मैं सिर्फ यह जानना चाहता हूं कि अधिकांश समय बर्बाद होने वाले लक्ष्य क्या हैं।

इसके अलावा, ऐसा लगता है कि जीसीसी प्रीकंपील्ड हेडर से निपटने में काफी अक्षम है। मैं किसी भी उपप्रोजेक्ट को विशेष रूप से तेज़ बनाने में असमर्थ था, मुझे मिलने वाली अधिकतम गति एक परियोजना पर 20% है जो निर्माण के लिए तीन मिनट लगती है। ऐसा लगता है कि जीसीसी के साथ लिनक्स पर निर्माण समय को अनुकूलित करने के बजाय ठोस राज्य ड्राइव के साथ तेज मशीन खरीदने के लिए यह आसान और सस्ता है।

Answer 1

यदि आप इस सुविधा से अधिक लाभ उठाना चाहते हैं, तो आपको यह समझने की आवश्यकता है कि आपकी परियोजनाओं का अच्छा उपयोग करने के लिए कैसे संरचित किया जा सकता है। सबसे अच्छा तरीका मैन्युअल रूप से बिल्डिंग समय को कम करने की धीमी, कठिन प्रक्रिया है। पहले वास्तव में बेवकूफ लगता है, लेकिन यदि आगे बढ़ने वाला सभी 5 गुना तेज है और आप जानते हैं कि अपनी परियोजनाओं और निर्भरताओं को आगे बढ़ने के तरीके को कैसे व्यवस्थित किया जाए - तो आप भुगतान का एहसास करते हैं।

आप सेटअप को मापने और अपनी प्रगति/सुधार रिकॉर्ड के रूप में अपने परिवर्तन में आते हैं।

करने के लिए अपने लक्ष्य के साथ एक सतत एकीकरण प्रणाली मैं एक बड़ी परियोजना है, कुछ सी ++ कोड के बारे में 150 000 एल ओ सी हो सकता है। समय बनाना लगभग 15 मिनट है। इस परियोजना में विभिन्न आकारों की कई उप-परियोजनाएं शामिल हैं।

लगता है कि यह बहुत ही अनावश्यक काम कर रहा है, मान लीजिए कि आपके पास आधुनिक मशीन है।

लिंक समय पर भी विचार करें।

मेरे सभी प्रीकंपील्ड हेडर बहुत बड़े नहीं हैं, प्रत्येक फ़ाइल लगभग 50 एमबी है।

यह बहुत बड़ा है, आईएमओ।

मैं निर्भरता विश्लेषण या कुछ उन्नत के बारे में बात नहीं कर रहा हूं।

फिर से, आंकड़ों के लिए निरंतर एकीकरण।धीमी गति के निर्माण के लिए, अत्यधिक निर्भरताएं इस मुद्दे पर बहुत अधिक संभावनाएं हैं (जब तक आपके पास कई छोटी सीपीपी फाइलें न हों, या भौतिक स्मृति थकावट की तरह मूर्खतापूर्ण कुछ हो रहा हो)।

मुझे लगता है कि मैं 20%

अपने ढांचे और निर्भरता को समझें है किसी भी subproject निर्माण विशेष रूप से तेजी से प्राप्त करने में असमर्थ, अधिकतम speedup था। पीसीएच मेरी अधिकांश परियोजनाओं को धीमा कर देती है।

ऐसा लगता है कि जीसीसी के साथ लिनक्स पर निर्माण समय को अनुकूलित करने के लिए ठोस राज्य ड्राइव के साथ तेज मशीन खरीदने के लिए यह आसान और सस्ता है।

संभावना है कि, कि मशीन अपने निर्भरता को फिक्सिंग अपने निर्माण के समय 20x तेजी से है, लेकिन नहीं होगा और इस परियोजना संरचनाओं कर सकते हैं यह 20x तेजी (या जो भी समस्या के मूल अंततः है)। मशीन केवल इतना मदद करती है (150KSLOC के लिए निर्माण समय पर विचार करें)।

आपका निर्माण शायद सीपीयू/मेमोरी बाध्य है।

Answer 2

जीसीसी का निर्माण समय precompiled हेडर

हाँ से ज्यादा लाभ नहीं होता, दुर्भाग्य है कि अक्सर सच है,

कुछ बेहतर करने के लिए कुछ प्रायोगिक परियोजनाओं रहे हैं, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3426.html और http://gcc.gnu.org/wiki/pph देखते हैं, लेकिन वे अभी तक उपयोग योग्य नहीं हैं।

मैं दूसरे उत्तर से सहमत हूं कि 150KLOC के लिए 15 मिनट काफी धीमी है।

मुझे पता चला है कि Gold लिंकर का उपयोग समय बनाने के लिए एक बड़ा अंतर बनाता है, मैं अत्यधिक अनुशंसा करता हूं।

तुम भी ccache जो मदद कर सकते हैं विचार कर सकते हैं, और यदि आप धीमी गति से डिस्क पर distcc

बचें निर्माण अन्य मशीनों पर अतिरिक्त चक्र है, निश्चित रूप से नेटवर्क डिस्क से बचें। रिकर्सिव इनवोकेशन बनाने से बचें, जो मेकफ़ाइल पढ़ने और निर्भरता ग्राफ को पुनर्निर्मित करने में अधिक समय व्यतीत करते हैं। यदि आप अपने उप-प्रोजेक्ट मेकफ़ाइल को ढांचा बना सकते हैं, तो उन्हें सभी को एक शीर्ष-स्तरीय मेकफ़ाइल द्वारा शामिल किया जा सकता है, एक गैर-रिकर्सिव मेक शुरू करने में थोड़ा समय लगेगा लेकिन लक्ष्य बनाने के बाद यह उड़ जाएगा। यद्यपि मेकफ़ाइल को फिर से लिखने के लिए यह बहुत काम हो सकता है।

और यह शायद कह बिना चला जाता है, लेकिन एक मल्टीकोर मशीन पर निर्माण और make -j N का उपयोग जहां अंगूठे का एक अच्छा नियम है कि N दो बार कोर की संख्या, या अधिक होना चाहिए, अगर संकलन आई/ओ बाध्य है।

Answer 3

मैं उपयोग करता हूं- पीएचसी उत्पन्न करने और उपयोग करने के दौरान शामिल करें जिसमें एक फ़ाइल शामिल है जिसमें बहुत सारे शीर्षलेख शामिल हैं। यह मदद करता है, लेकिन यह अभी भी प्रभावशाली नहीं है।

अपने आशीर्वादों की गणना करें, हालांकि: एमएसवीसी, एमएसवीसी के बेहतर पीसीएच समर्थन के बावजूद जीसीसी कई गुना तेजी से प्रतीत होता है।