हमारे पास बहुत सी साझा वस्तुओं (.so) के साथ एक बहुत ही मॉड्यूलर एप्लिकेशन है। कुछ लोग तर्क देते हैं कि सीमित मेमोरी/फ्लैश वाले कम-अंत प्लेटफ़ॉर्म पर, साझा वस्तुओं के ऊपर की ओर बढ़ने के साथ-साथ सभी को एक बड़े निष्पादन योग्य में स्थिर रूप से लिंक करना बेहतर होता है।साझा ऑब्जेक्ट ओवरहेड
इस पर आपकी राय क्या है?
शुभकामनाओं सहित,
पॉल
स्मृति तक अत्यधिक तंग है, इन फ़ाइलों की एक प्रति का आकार प्राथमिक निर्धारण कारक नहीं है। यह देखते हुए कि यह एक एम्बेडेड सिस्टम है, शायद आपके पास एक अच्छा विचार है कि आपके पुस्तकालयों का उपयोग कब और कौन सा होगा। यदि आपका एप्लिकेशन एकाधिक पुस्तकालयों को खोलता है और बंद करता है तो यह कर्तव्यपूर्वक संदर्भित करता है, और आपके पास कभी भी सभी पुस्तकालय एक साथ खुलते नहीं हैं, फिर साझा लाइब्रेरी रैम में एक महत्वपूर्ण बचत होगी।
अन्य कारक जो आपको विचार करने की आवश्यकता है वह प्रदर्शन जुर्माना है। साझा लाइब्रेरी खोलना एक छोटी (आमतौर पर मामूली) समय लेता है; यदि आपके पास बहुत धीमी प्रोसेसर या हार्ड-टू-हिट रीयल-टाइम आवश्यकताएं हैं, तो स्थिर लाइब्रेरी साझा लाइब्रेरी के लोडिंग पेनल्टी को नहीं लेगी। यह पता लगाने के लिए प्रोफाइल कि यह महत्वपूर्ण है या नहीं।
समेकित करने के लिए, साझा पुस्तकालय कुछ विशेष मामलों में स्थिर पुस्तकालयों की तुलना में काफी बेहतर हो सकते हैं। ज्यादातर मामलों में, वे कोई नुकसान नहीं करते हैं। सरल परिस्थितियों में, आपको साझा पुस्तकालयों से कोई फायदा नहीं होता है।
बेशक, साझा लाइब्रेरी यदि आप एक से अधिक आवेदन (या अपने आवेदन के संस्करण) जो एक ही पुस्तकालय का उपयोग किया है फ्लैश में एक महत्वपूर्ण बचत हो जाएगा। यदि आप एक स्थिर पुस्तकालय का उपयोग करते हैं, तो एक प्रति (जो साझा लाइब्रेरी के समान आकार के बारे में है [1]) प्रत्येक में संकलित की जाएगी। जब आप पीसी वर्कस्टेशन पर होते हैं तो यह उपयोगी होता है। लेकिन आप उसे जानते थे। आप एक पुस्तकालय के साथ काम कर रहे हैं जिसका उपयोग केवल एक आवेदन द्वारा किया जाता है।
[1] व्यक्तिगत लाइब्रेरी फ़ाइलों का स्मृति अंतर छोटा है। साझा पुस्तकालय एक अनुक्रमणिका और प्रतीक तालिका जोड़ते हैं ताकि dlopen(3) लाइब्रेरी लोड कर सके। चाहे यह महत्वपूर्ण है या नहीं, आपके उपयोग के मामले पर निर्भर करेगा; प्रत्येक के लिए संकलित करें और फिर आकार में तुलना करें कि फ्लैश में कौन सा छोटा है। आपको यह निर्धारित करने के लिए दौड़ना होगा कि प्रोफाइल अधिक रैम का उपभोग करता है; साझा पुस्तकालय की प्रारंभिक लोडिंग को छोड़कर उन्हें समान होना चाहिए।
पाठ्यक्रम के पुस्तकालयों के बहुत सारे होने का मतलब है अधिक मेटा डेटा संग्रहीत किया जाना चाहिए, और यह भी कि मेटा डेटा के कुछ (पुस्तकालय अनुभाग शीर्ष लेख आदि) होने की आवश्यकता होगी लोड होने पर रैम में संग्रहीत। लेकिन अंतर बहुत ही नगण्य होना चाहिए, यहां तक कि (मध्यम आधुनिक) एम्बेडेड सिस्टम पर भी।
मेरा सुझाव है कि आप दोनों विकल्पों को आज़माएं, और फ्लैश और रैम दोनों में उपयोग की गई जगह को मापें, और फिर तय करें कि कौन सा सर्वोत्तम है।
साझा पुस्तकालयों की लागत (पुस्तकालय प्रति) मोटे तौर पर कर रहे हैं:
mmap और mprotect सिस्कोल, और लोड समय पर कम से कम एक पेज गलती।प्लस स्थिति स्वतंत्र कोड लागत:
यदि आपके पास लंबे समय तक चलने वाला एप्लिकेशन है, तो लागत आपके लिए कोई फर्क नहीं पड़ता है, जब तक कि आप एक छोटे से एम्बेडेड सिस्टम पर न हों। दूसरी तरफ, यदि आप ऐसा कुछ लिख रहे हैं जिसे छोटे कार्यों (जैसे भाषा दुभाषिया) के लिए कई बार बुलाया जा सकता है तो ये लागत बड़ी हो सकती है। सभी मानक मॉड्यूल को अपने .so फ़ाइलों में डिफ़ॉल्ट रूप से लिंक करने के बजाय डिफ़ॉल्ट रूप से डालने का एक बड़ा हिस्सा है, क्यों पर्ल, पायथन आदि शुरू करने में धीमे हैं।
व्यक्तिगत रूप से, मैं नहीं एक विकास मॉडल के रूप में, एक तानाना उपकरण के रूप में गतिशील लोड मॉड्यूल का उपयोग करने का रणनीति के साथ जाना होगा।