2009-10-13 6 views
5

मेरे पास एक सी ++ लाइब्रेरी है जो बहुत बड़ा कोड उत्पन्न करती है जिसे मैं वास्तव में उम्मीद कर रहा हूं कि यह क्या कर रहा है। स्रोत की 50K से कम लाइनों से मुझे साझा ऑब्जेक्ट मिलते हैं जो लगभग 4 एमबी और स्थिर अभिलेखागार 9 को दबाते हैं। यह समस्याग्रस्त दोनों है क्योंकि लाइब्रेरी बाइनरी काफी बड़ी हैं, और इससे भी बदतर, इसके खिलाफ जुड़ी सरल एप्लिकेशन भी आम तौर पर 500 से 1000 प्राप्त करती हैं कोड आकार में केबी। लाइब्रेरी के साथ लाइब्रेरी को संकलित करना -ओएस कुछ हद तक मदद करता है, लेकिन वास्तव में बहुत ज्यादा नहीं।सी/सी ++ अनुप्रयोगों में अत्यधिक कोड आकार को प्रोफाइल करने के लिए कुछ तकनीक या उपकरण क्या हैं?

मैंने जीसीसी के -फ्रेपो कमांड के साथ भी प्रयोग किया है (भले ही मैंने देखा है कि सभी दस्तावेज बताते हैं कि लिनक्स संग्रह 2 पर डुप्लिकेट टेम्पलेट्स को मर्ज करेगा) और टेम्पलेट्स पर स्पष्ट टेम्पलेट इंस्टेंटेशन जो "संभावना" को बहुत अधिक डुप्लिकेट करने लग रहा था , लेकिन किसी भी मामले में कोई वास्तविक प्रभाव नहीं है। बेशक मैं "संभावना" कहता हूं क्योंकि, किसी भी प्रकार की प्रोफाइलिंग के साथ, इस तरह के अंधेरे अनुमान लगभग हमेशा गलत होते हैं।

क्या कोई ऐसा उपकरण है जो कोड आकार को आसान बनाता है, या किसी अन्य तरीके से मैं यह पता लगा सकता हूं कि इतना अधिक कमरे क्या ले रहा है, या अधिक आम तौर पर, मुझे किसी अन्य चीज की कोशिश करनी चाहिए? लिनक्स के तहत काम करने वाला कुछ आदर्श होगा लेकिन मैं जो भी प्राप्त कर सकता हूं वह ले जाऊंगा।

उत्तर

7

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

यदि आप सीधे एलडी का आविष्कार नहीं कर रहे हैं, लेकिन केवल जीसीसी कमांड लाइन के माध्यम से, आप जीडी कमांड लाइन से ld विशिष्ट विकल्पों को -Wl, से पहले एलडी में पास कर सकते हैं।

+0

यह '-W1' नहीं है, यह' -Wl' –

+0

@FX है - इसे ढूंढने के लिए धन्यवाद। मैंने इसे ठीक कर दिया है। –

1

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

2

लिनक्स पर लिंकर निश्चित रूप से एकाधिक टेम्पलेट तत्काल विलय करता है।

सुनिश्चित करें कि आप डीबग बाइनरी को माप नहीं रहे हैं (डीबग जानकारी अंतिम बाइनरी आकार के 75% से अधिक ले सकती है)।

अंतिम बाइनरी आकार को कम करने के लिए एक तकनीक -ffunction-sections और -fdata-sections के साथ संकलित करना है, फिर -Wl,--gc-sections से लिंक करें।

भी बड़ा कमी (हम 25% देखा है) यदि आप -Wl,--icf

एक और उपयोगी तकनीक है के साथ (binutils का हिस्सा नई परी-केवल लिंकर,) [gold][1] के विकास के संस्करण, और लिंक का उपयोग संभव हो सकता है उन प्रतीकों के सेट को कम करना जो आपके साझा पुस्तकालयों द्वारा "निर्यात" किए जाते हैं (सब कुछ डिफ़ॉल्ट रूप से निर्यात किया जाता है), या तो __attribute__((visibility(...))) के माध्यम से, या लिंकर स्क्रिप्ट का उपयोग करके। विवरण here (देखें "निर्यात नियंत्रण")।

संबंधित मुद्दे

 संबंधित मुद्दे