मेरे पास एक ऐसी परियोजना है जिसमें g ++ और ld से लिंक करने में लगभग 8 सेकंड लगते हैं।सी ++ लिंकिंग समय को कम करने पर युक्तियाँ
यह स्थिर पुस्तकालयों का एक समूह का उपयोग करता है, अधिकांश कोड सी ++ है।
मुझे लिंक समय को कम करने के तरीकों की एक सामान्य सूची में रूचि है। से कुछ भी
मैंने पिछले कुछ वर्षों से इस के साथ निपटाया। बड़ी संख्या में स्थैतिक पुस्तकालयों को जोड़ने के दौरान जीएनयू लिंकर में गंभीर प्रदर्शन समस्याएं होती हैं। एक बिंदु पर, लिंक समय संकलन समय के बराबर था, जिसे हमने बहुत अजीब पाया, हमने वास्तव में इसकी जांच की और इसे समझ लिया।
आप लिंक करने से पहले अपने स्थिर पुस्तकालयों को "सुपर ऑब्जेक्ट" में मर्ज करने का प्रयास कर सकते हैं। इस प्रकार की जोड़ने की:
$ g++ -o program program.o $STATIC_LIBS
आप इस कोशिश कर सकते:
$ ld -r -o libraries.o --whole-archive $STATIC_LIBS
$ g++ -o program program.o libraries.o
नोट इस विधि अप्रयुक्त वस्तु कोड को बाहर करने के संयोजक कम अवसर देता है, तो उसे अपनी बाइनरी कुछ हद तक आकार में वृद्धि हो सकती है।
यदि आप C++ कोड के लिए इस विधि का उपयोग करते हैं, तो आपको '-r' के बजाय' -उआर' स्विच की आवश्यकता हो सकती है ('ld' के लिए प्रलेखन देखें) – anatolyg
क्या सी ++ कोड के लिए यूआरएक्स समाधान है? ऐसा लगता है कि osx10.6 पर ld पहचान नहीं है -उआर –
यह देखकर मुझे आश्चर्य है कि कनेक्टिंग निर्भरता पहले बेहतर प्रदर्शन प्रदान करेगी। – Alex
8 सेकंड बहुत तेजी से है, जब तक आप वास्तव में लगता है कि यह है कि लंबे समय से नहीं लेना चाहिए रहे हैं "अपने कोड कम spagetti बनाने के" से "डिबग प्रतीक शामिल न"। मेरे पास ऐसी परियोजनाएं हैं जो पूर्ण रिलिक के लिए 5-8 मिनट लगती हैं क्योंकि हम अपने रिलीज बिल्ड पर वृद्धिशील लिंक नहीं करते हैं। क्या आपने वृद्धिशील लिंकिंग का उपयोग करने का प्रयास किया है (यदि आप -shared का उपयोग नहीं कर रहे हैं, तो आप -i या -r का उपयोग कर सकते हैं)?
5-8 मिनट अभी भी एक अखरोट की तरह दिखता है। –
@ मार्टिन: ऐसा नहीं है, मैं 1.2 मिलीलीटर लॉक सी ++ कोडबेस पर काम करता हूं, जो बूस्ट, जीएमपी और कुछ अन्य ग़रीब पुस्तकालयों का उपयोग करता है, अच्छे डिज़ाइन, डिस्क (8 सर्वर), फास्ट डिस्क आदि का उपयोग करके, संपूर्ण कोडबेस का पूर्ण निर्माण (परीक्षण सहित) जीसीसी 4.4 का उपयोग करके लगभग 2-2.5 मिनट लेता है - तो कुछ 8 मिनट लेने के लिए, यह वास्तव में वास्तव में खराब लिखित या विशाल कोडबेस होना होगा। –
या एक तेज सर्वर पर नहीं चल रहा है ... – Jay
पूरे कार्यक्रम अनुकूलन को बंद करें (कम से कम विकास के दौरान)। निर्भरताओं को कम करने के लिए पी-इंप्यू का प्रयोग करें।
पी संकुचित नहीं है * संकलन * समय को कम करने के लिए? – Simone
@ सिमोन: पी-इफ्लो का अर्थ है कि एक वर्ग के कार्यान्वयन में परिवर्तन के लिए सभी उपभोक्ताओं की बजाय केवल एक एकल संकलन इकाई को पुन: संकलित करने की आवश्यकता होती है। कम संकलन इकाइयों में वृद्धि से वृद्धिशील लिंकिंग अधिक प्रभावी बनाता है। –
साझा पुस्तकालयों के रूप में डीबग बिल्ड को संकलित करने के बारे में कैसे? इससे डीबग प्रतीक ब्लोट को हल किया जाएगा, क्योंकि आयात पुस्तकालय डीबग जानकारी के साथ या बिना छोटे हैं। शायद सबसे अच्छा समाधान नहीं है, लेकिन मुझे लगता है कि यह लिंक समय को काफी हद तक कम कर देगा ...
उन्होंने विशेष रूप से कहा कि साझा पुस्तकालय बाहर थे। और मैं उससे सहमत हूं - आधुनिक प्रणालियों पर, साझा पुस्तकालयों में कई संभावित मुद्दे शामिल हैं और आपको कुछ फायदे हैं। –
@TomSwirly कहीं भी मैं देख सकता हूं कि वह साझा पुस्तकालयों के खिलाफ होने का उल्लेख करता है। – rubenvb
रैमडिस्क बनाएं, उस पर संकलित करें और हार्डडिस्क से लिंक करें।
चूंकि आप बहुत से स्थिर पुस्तकालयों का उपयोग कर रहे हैं, तो आप एक विशाल लाइब्रेरी बना सकते हैं जिसमें सभी थियो पुस्तकालय शामिल हैं ताकि आप एक लाइबेरे के साथ समाप्त हो सकें। अपनी lib-list से सभी पुस्तकालयों को हटा दें और वें विशाल जोड़ें। इससे पुस्तकालयों के लिए फ़ाइल की 1 तक खुलती है और पढ़ने की क्रिया तेज हो सकती है।
क्या हम 1 9 80 के दशक में उस चीज को रैमडिस्क नहीं करते थे? – anatolyg
@anatolyg: हाँ, लेकिन यह अभी भी हार्डडिस्क धड़कता है। –
वह एक एसएसडी _has_! –
क्या आप [लिंक टाइम कोड पीढ़ी] (http://gcc.gnu.org/wiki/LinkTimeOptimization) का उपयोग कर रहे हैं? यह तेजी से कोड उत्पन्न करेगा लेकिन लिंक का समय बढ़ जाएगा। –
8 सेकंड तेज है। यह चिंता करने के लिए ज्यादा पसंद नहीं है। परियोजना कितनी बड़ी है? –
प्लेटफार्म और कंपाइलर? जीसीसी और बिनुटिल्स के साथ, [सोना] (http://sourceware.org/ml/binutils/2008-03/msg00162.html) अधिकतर (क्लासिक) एलडी से अधिक तेज़ है, और [क्लैंग] (http: //clang.llvm .org /) उस से तेज (या हो सकता है) हो सकता है। – ephemient