सीपीपी अनुवाद इकाइयों की संख्या को कम करना एक अच्छा विचार है?

Question

मुझे लगता है कि यदि कई कक्षाएं हैं तो संकलन समय नाटकीय रूप से बढ़ता है जब मैं प्रति वर्ग एक * .h और एक * .cpp फ़ाइल का उपयोग करता हूं। मैं पहले से ही precompiled हेडर और वृद्धिशील जोड़ने का उपयोग करें, लेकिन अभी भी संकलन समय बहुत लंबा है (बढ़ावा हाँ मैं का उपयोग करें;)

तो मैं निम्नलिखित चाल के साथ आया था:

• परिभाषित * सीपीपी गैर के रूप में फाइल -compilable
• परिभाषित * .cxx फ़ाइलों compilable रूप
• प्रति आवेदन मॉड्यूल एक * .cxx फ़ाइल जोड़ा, और उस में इस मॉड्यूल के सभी * सीपीपी फ़ाइलों #included।

तो 100+ अनुवाद इकाइयों के बजाय मैं केवल 8 अनुवाद इकाइयों के साथ समाप्त हुआ। संकलन समय 4-5 गुना छोटा हो गया।

डाउनसाइड्स यह है कि आपको सभी * .cpp फ़ाइलों को मैन्युअल रूप से शामिल करना होगा (लेकिन यह वास्तव में एक रखरखाव दुःस्वप्न नहीं है क्योंकि अगर आप कुछ लिंकर आपको याद दिलाना चाहते हैं), और कुछ वीएस आईडीई सुविधाएं काम नहीं कर रही हैं इस योजना के साथ, उदाहरण के लिए कार्यान्वयन आदि पर जाएं/स्थानांतरित करें

तो सवाल यह है कि, बहुत सी सीपीपी अनुवाद इकाइयां वास्तव में एकमात्र सही तरीका है? क्या मेरी चाल एक ज्ञात पैटर्न है, या शायद मुझे कुछ याद आ रहा है? धन्यवाद!

Answer 1

अवधारणा को unity build

Answer 2

मैंने देखा है कि आप वीडियो गेम में क्या करते हैं क्योंकि यह संकलक को अनुकूलन करने में मदद करता है अन्यथा यह नहीं कर सकता है और साथ ही साथ बहुत सारी मेमोरी भी बचा सकता है। मैंने "उबर बिल्ड" और "थोक निर्माण" देखा है इस विचार का संदर्भ लें। और यदि यह आपके निर्माण को तेज करने में मदद करता है, क्यों नहीं ..

Answer 3

इस दृष्टिकोण का एक महत्वपूर्ण दोष प्रत्येक अनुवाद इकाई के लिए एक .obj फ़ाइल होने के कारण होता है।

यदि आप अन्य परियोजनाओं में पुन: उपयोग के लिए एक स्थिर पुस्तकालय बनाते हैं तो आप अक्सर उन परियोजनाओं में बड़ी बाइनरी का सामना करेंगे यदि आपके पास कई छोटे लोगों की बजाय कई विशाल अनुवाद इकाइयां हैं क्योंकि लिंकर में केवल .obj फ़ाइलें शामिल होंगी जिनमें फ़ंक्शंस/पुस्तकालय का उपयोग कर परियोजना के भीतर वास्तव में संदर्भित चर।

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

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

Answer 4

बड़ी और कम अनुवाद इकाइयां समानांतर संकलन का लाभ नहीं लेती हैं। मुझे नहीं पता कि आप कौन से कंपाइलर्स और प्लेटफॉर्म का उपयोग कर रहे हैं, लेकिन समानांतर एकाधिक अनुवाद इकाइयों में संकलन भवन के समय में काफी कमी कर सकता है ...

Answer 5

एक फ़ाइल में बड़ी संख्या में सी ++ स्रोत कोड फ़ाइलों को बंडल करना एक दृष्टिकोण है हाल ही में कुछ बार उल्लेख किया गया है, खासकर जब लोग बड़े सिस्टम बना रहे थे और जटिल हेडर फाइलों में खींच रहे थे (जो तब बढ़ावा देंगे)।

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

सी ++ विकास के लिए "बहुत संकलन इकाइयां" दृष्टिकोण आम तौर पर कक्षाओं को कम करने और वर्गों के बीच निर्भरता को कम करने की इच्छा से आता है ताकि संकलक को केवल कुछ बदलाव करने के मामले में फ़ाइलों के न्यूनतम सेट को पुनर्निर्माण करना होगा। यह आम तौर पर एक अच्छा दृष्टिकोण होता है लेकिन अक्सर उपप्रोजेक्ट में वास्तव में व्यवहार्य नहीं होता है क्योंकि वहां की फ़ाइलों में एक दूसरे पर निर्भरता होती है ताकि आप वैसे भी बड़े पुनर्निर्माण के साथ समाप्त हो जाएंगे।

Answer 6

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

Answer 7

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

Answer 8

मुझे नहीं लगता कि संकलन इकाइयों की संख्या में कमी एक अच्छा विचार है। आप बड़े संकलन समय के साथ एक समस्या को हल करने की कोशिश कर रहे हैं, और यह दृष्टिकोण इसके साथ मदद करता है, लेकिन इसके अलावा आपको क्या मिलता है:

1. विकास के दौरान संकलन समय बढ़ाया। आम तौर पर डेवलपर एक समय में कुछ फ़ाइलों को संशोधित करता है, और संकलन 3-4 छोटी फ़ाइलों के लिए शायद एक बहुत बड़ी फ़ाइल के लिए तेज़ होगा।
2. जैसा कि आपने बताया है, कोड नेविगेट करना कठिन है, IMHO यह बेहद महत्वपूर्ण है।

   एक:

3. आप सीपीपी फ़ाइलों के बीच कुछ हस्तक्षेप एक .cxx फ़ाइल में शामिल हो सकता है। स्मृति रिसाव जांच के लिए मैक्रो नए सीपीपी फ़ाइल (डीबग बिल्ड के लिए) में स्थानीय रूप से परिभाषित करना आम बात है। दुर्भाग्यवश यह प्लेसमेंट नया (कुछ एसटीएल और बूस्ट हेडर डू के रूप में) हेडर का उपयोग करने से पहले नहीं किया जा सकता है

   बी। सीपीपी फाइलों में घोषणाओं का उपयोग करना सामान्य बात है। आपके दृष्टिकोण के साथ यह हेडर के साथ समस्याएं पैदा कर सकता है, बाद में

   सी शामिल है। नाम संघर्ष अधिक संभावित हैं

IMHO, अधिक स्वच्छ (लेकिन शायद अधिक महंगा तरीका) संकलन समय तेजी लाने के लिए कुछ वितरित निर्माण प्रणाली का उपयोग करने के लिए है। वे स्वच्छ निर्माण के लिए विशेष रूप से प्रभावी हैं।