जीसीसी/बिल्ड समय अनुकूलन बनाएं

Question

हमारे पास ऐसी परियोजना है जो जीसीसी का उपयोग करती है और फाइलें बनाती है। परियोजना में एक बड़े उपप्रोजेक्ट (एसडीके) और अपेक्षाकृत छोटे सबप्रोजेक्ट्स शामिल हैं जो एसडीके और कुछ साझा ढांचे का उपयोग करते हैं।

हम प्रीकंपील्ड हेडर का उपयोग करते हैं, लेकिन यह केवल पुनः संकलन के लिए तेज़ी से मदद करता है।

क्या बिल्ड-टाइम अनुकूलन में सहायता के लिए कोई ज्ञात तकनीक और उपकरण हैं? या शायद आप इस या संबंधित विषयों के बारे में कुछ लेख/संसाधन जानते हैं?

Answer 1

आप दो पक्षों से समस्या का सामना कर सकते हैं: संकलक को देख रहे जटिलता को कम करने के लिए कोड को दोबारा दोहराएं, या संकलक निष्पादन को तेज करें।

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

कोड को पुन: सक्रिय करना। आगे बढ़ने के लिए आगे की घोषणा पसंद करें (सरल)। निर्भरता से बचने के लिए जितना संभव हो उतना कम करें (पीआईएमपीएल मुहावरे का उपयोग करें)।

टेम्पलेट इंस्टेंटेशन महंगा है, उन्हें उपयोग करने वाली प्रत्येक संकलन इकाई में पुन: संकलित किया जाता है। यदि आप उन्हें घोषित करने के लिए अपने टेम्पलेट्स को दोबारा कर सकते हैं और फिर उन्हें केवल एक संकलन इकाई में तुरंत चालू कर सकते हैं।

Answer 2

make के साथ सबसे अच्छा मैं -j विकल्प के साथ सोच सकता हूं। यह make बताता समानांतर में यथासंभव अधिक से अधिक रोजगार के अवसर को चलाने के लिए:

make -j

आप के लिए एन समवर्ती नौकरियों की संख्या सीमित करना चाहते हैं आप का उपयोग कर सकते हैं:

make -jn

---

सुनिश्चित करें कि निर्भरता सही हैं इसलिए make नौकरियों को चलाने में काम नहीं करता है करने के लिए नहीं है।

---

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

---

डिबग जानकारी (gcc -g) के साथ संकलन शायद अपने निष्पादन के आकार में वृद्धि होगी और अपने निर्माण के समय को प्रभावित कर सकता। अगर आपको इसकी आवश्यकता नहीं है, तो यह देखने के लिए इसे हटाने का प्रयास करें कि यह आपको प्रभावित करता है या नहीं।

---

लिंकिंग (स्थिर बनाम गतिशील) के प्रकार में एक अंतर होना चाहिए। जहां तक ​​मैं समझता हूं कि स्थिर लिंकिंग अधिक समय लेती है (हालांकि मैं यहां गलत हो सकता हूं)। आपको देखना चाहिए कि यह आपके निर्माण को प्रभावित करता है या नहीं।

Answer 3

यदि आपके पास डेवलपर मशीनों के साथ एक लैन है, तो शायद आपको distcc जैसे वितरित कंपाइलर समाधान को लागू करने का प्रयास करना चाहिए।

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

Answer 4

http://ccache.samba.org/ बड़े समय में गति करता है।

मैं एक मध्यम आकार की परियोजना पर काम करता हूं, और यह एकमात्र चीज है जिसे हम संकलन समय को तेज करने के लिए करते हैं।

Answer 5

यदि आपके पास एकाधिक कंप्यूटर उपलब्ध हैं तो जीसीसी अच्छी तरह से distcc द्वारा वितरित किया जाता है।

आप इसके अलावा ccache का भी उपयोग कर सकते हैं।

यह सब मेकफ़ाइल के बहुत कम परिवर्तनों के साथ काम करता है।

Answer 6

प्रोजेक्ट के विवरण से मुझे लगता है कि आपके पास प्रति मेकफ़ाइल एक मेकफ़ाइल है और रिकर्सिव का उपयोग कर बहुत कुछ कर रहा है। उस मामले में "Recursive Make Considered Harmful" से तकनीक बहुत मदद करनी चाहिए।

Answer 7

इसके अलावा, आप शायद छोटे और आत्म निहित संभव/संभव के रूप में है, यानी एक विशाल एकल ऑब्जेक्ट फ़ाइल पर कई छोटे वस्तु फ़ाइलों को पसंद करते हैं के रूप में अपने स्रोत कोड फ़ाइलों को रखना चाहता हूँ।

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

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

इसके अलावा, आप GNU gold linker का उपयोग करना भी देख सकते हैं, जो much more efficient है जो ईएलएफ लक्ष्यों के लिए सी ++ कोड संकलित करने के लिए है।

असल में, मैं आपको सलाह देता हूं कि आप अपनी बिल्ड प्रक्रिया को सावधानीपूर्वक प्रोफाइल करें और जांचें कि अधिकतर समय कहां खर्च किया जाता है, जो आपको अपनी बिल्ड प्रक्रिया या अपनी परियोजनाओं के स्रोत कोड संरचना को अनुकूलित करने के तरीके के बारे में कुछ संकेत देगा।

Answer 8

आप distcc वितरित संकलक का उपयोग निर्माण के समय को कम करने के लिए आप कई मशीनों का उपयोग किया है, तो कर सकते हैं। यहाँ distcc से संबंधित आईबीएम डेवलपर से से एक लेख है और आप इसे कैसे उपयोग कर सकते हैं: http://www.ibm.com/developerworks/linux/library/l-distcc.html

निर्माण समय को कम करने एक अन्य विधि precompiled हेडर का उपयोग करने के लिए है। यहां एक starting point for gcc है।

इसके अलावा जब मेकअप के साथ निर्माण करता है, तो अपने मशीन एक से अधिक CPU/कोर -j उपयोग करने के लिए मत भूलना (कोर की संख्या 2x/CPUs ठीक है)।

Answer 9

आप इस तरह के SCons रूप में एक अलग निर्माण प्रणाली में परिवर्तित हो (जो स्पष्ट रूप से हर किसी के लिए काम नहीं करेगा), विचार कर सकते हैं। स्कैन बनाने से ज्यादा चालाक है। यह स्वचालित रूप से हेडर निर्भरताओं को स्कैन करता है, इसलिए आपके पास हमेशा पुनर्निर्माण निर्भरताओं का सबसे छोटा सेट होता है।अपनी स्कैनस्ट्रक्चर फ़ाइल में Decider('MD5-timestamp') लाइन जोड़कर, स्कैन पहले फ़ाइल के समय के टिकट को देखेंगे, और यदि यह पहले निर्मित टाइम स्टैंप से नया है, तो यह सुनिश्चित करने के लिए कि आप वास्तव में कुछ बदल चुके हैं, यह फ़ाइल के MD5 का उपयोग करेगा। यह केवल स्रोत फ़ाइलों पर काम नहीं करता है बल्कि फ़ाइलों को भी ऑब्जेक्ट करता है। इसका अर्थ यह है कि यदि आप कोई टिप्पणी बदलते हैं, उदाहरण के लिए, आपको फिर से लिंक करने की आवश्यकता नहीं है।

हेडर फ़ाइलों की स्वत: स्कैनिंग ने यह भी सुनिश्चित किया है कि मुझे स्कैन - स्कैनन टाइप करने की आवश्यकता नहीं है। यह हमेशा सही काम करता है।

Answer 10

छोटी फ़ाइलों का उपयोग करना हमेशा एक अच्छी सिफारिश नहीं हो सकता है। एक डिस्क में 32 या 64 के न्यूनतम क्षेत्र का आकार होता है, जिसमें फ़ाइल कम से कम एक क्षेत्र लेती है। तो 3K आकार (अंदर छोटा कोड) की 1024 फाइलें वास्तव में अपेक्षित 3 मेगापिक्सल की बजाय डिस्क पर 32 या 64 मेगापिक्सल लेती हैं। 32/64 मेग जिसे ड्राइव द्वारा पढ़ा जाना चाहिए। यदि डिस्क पर फ़ाइलों को चारों ओर फैलाया जाता है तो आप समय के साथ पढ़ने के समय को और भी बढ़ाते हैं। यह डिस्क कैश के साथ स्पष्ट रूप से, एक सीमा तक मदद मिली है। प्री-कंपाइल हेडर भी इसे कम करने में अच्छी मदद कर सकता है।

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