विंडोज मॉलोक प्रतिस्थापन (उदा।, टीसीएमएलओसी) और गतिशील सीआरटी

Question

ए सी ++ प्रोग्राम जो कई डीएलएल और क्यूटी का उपयोग करता है, को मॉलोक प्रतिस्थापन (tcmalloc) से लैस किया जाना चाहिए जो प्रदर्शन समस्याओं के लिए विंडोज मैलोक के कारण सत्यापित किया जा सकता है। लिनक्स के साथ, वहाँ कोई समस्या नहीं है, लेकिन खिड़कियों के साथ, वहाँ कई तरीके हैं, और मैं अपील कर उनमें से कोई भी पाते हैं:

1. lib में नए malloc रखो और लिंक करने के लिए सुनिश्चित करें कि यह पहली बार (Other SO-question)

इसका नुकसान है, उदाहरण के लिए strdup will still use the old malloc and a free may crash the program। lib.exe के साथ स्थिर libcrt पुस्तकालय से

2. हटाएँ malloc (क्रोम)

यह परीक्षण किया जाता है/chrome/chromium के लिए इस्तेमाल किया (?), लेकिन नुकसान यह है कि यह सिर्फ स्थिर CRT जोड़ने के साथ काम करता है । स्टेटिक लिंकिंग में समस्या है यदि एक सिस्टम लाइब्रेरी msvcrt के खिलाफ गतिशील रूप से जुड़ा हुआ है तो mismatches in the heap allocation/deallocation हो सकता है। अगर मैं इसे सही ढंग से समझता हूं, तो tcmalloc को गतिशील रूप से जोड़ा जा सकता है कि सभी स्वयं संकलित डीएलएस (जो अच्छा है) के लिए एक आम ढेर है।

3. पैच CRT-स्रोत कोड (फ़ायरफ़ॉक्स)

Firefox's jemalloc जाहिरा तौर पर खिड़कियों सीआरटी स्रोत कोड पैच और एक नया CRT बनाता है। यह फिर से स्थिर/गतिशील लिंकिंग समस्या है।

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

4. गतिशील रूप से चलाने के लिए समय

कुछ वाणिज्यिक स्मृति allocators इस तरह के जादू कर सकते हैं पर लोड सीआरटी पैचिंग। tcmalloc भी कर सकते हैं, लेकिन यह बदसूरत लगता है। इसमें कुछ समस्याएं थीं, लेकिन उन्हें ठीक कर दिया गया है। वर्तमान में, tcmalloc के साथ यह 64 बिट विंडोज़ के तहत काम नहीं करता है।

क्या बेहतर दृष्टिकोण हैं? कोई टिप्पणी?

Answer 1

आपका आधार "ए सी ++ प्रोग्राम जो कई डीएलएल और क्यूटी का उपयोग करता है उसे मॉलोक प्रतिस्थापन से लैस किया जाना चाहिए" से आते हैं?

विंडोज़ पर, यदि सभी डीएलएस साझा एमएसवीसीआरटी का उपयोग करते हैं, तो मॉलोक को बदलने की कोई आवश्यकता नहीं है। डिफ़ॉल्ट रूप से, क्यूटी साझा एमएसवीसीआरटी डीएल के खिलाफ बनाता है।

एक समस्याएं आ जाएंगे, बशर्ते:

1) मिश्रण DLLs कि साझा VCRT

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

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

Answer 2

प्रश्न: एक C++ प्रोग्राम है जो कई DLLs करवाते विभाजित है चाहिए:)

एक malloc की जगह?

बी) सुनिश्चित करें कि आवंटन और डी-आवंटन उसी डीएलएल मॉड्यूल में होता है?

ए: सही उत्तर बी है। एक सी ++ एप्लिकेशन डिज़ाइन जिसमें कई डीएलएल शामिल होते हैं, यह सुनिश्चित करना चाहिए कि एक डीएल में ढेर पर आवंटित चीजें सुनिश्चित करने के लिए एक तंत्र मौजूद है, उसी डीएलएल मॉड्यूल द्वारा मुक्त किया जाता है।

---

आप एक सी ++ प्रोग्राम को कई डीएलएस में क्यों विभाजित करेंगे? सी ++ प्रोग्राम से मेरा मतलब है कि आप जिन ऑब्जेक्ट्स और प्रकारों से निपट रहे हैं वे सी ++ टेम्पलेट्स, एसटीएल ऑब्जेक्ट्स, क्लासेस इत्यादि हैं। आप सीएल ++ ऑब्जेक्ट्स को बिना किसी सावधानीपूर्वक डिजाइन और बहुत सारे कंपाइलर विशिष्ट जादू, या पीड़ा के बिना डीएलएल सीमाओं में पारित नहीं कर सकते विभिन्न डीएलएस में ऑब्जेक्ट कोड के बड़े पैमाने पर डुप्लिकेशंस से, और नतीजतन एक ऐसा एप्लिकेशन जो अत्यंत संस्करण संवेदनशील है। कक्षा परिभाषा में कोई भी छोटा बदलाव सभी एक्सई और डीएल के पुनर्निर्माण को मजबूर करेगा, जिससे ऐप विकास के लिए डीएल दृष्टिकोण के कम से कम लाभों में से एक को हटा दिया जाएगा।

या तो ऐप और डीएल के बीच सीधी सी इंटरफ़ेस तक चिपकाएं, नरक पीड़ित करें, या बस पूरे सी ++ ऐप को एक एक्सई के रूप में संकलित करें।

Answer 3

nedmalloc? एनबी भी है कि smplayer malloc को ओवरराइड करने के लिए एक विशेष पैच का उपयोग करता है, जो उस दिशा में हो सकता है जिसमें आप आगे बढ़ रहे हैं।

Answer 4

यह एक बोल्ड दावा है कि एक सी ++ प्रोग्राम "प्रदर्शन समस्याओं के लिए एक मॉलोक प्रतिस्थापन (जैसे tcmalloc) से लैस होना चाहिए .... "

" [8] 8 लोकप्रिय मानकों में से 6 ... [वास्तविक आकार के अनुप्रयोग] कस्टम आवंटक को वापस लेते हैं, जिसमें लोगों ने महत्वपूर्ण मात्रा और धन का निवेश किया था .. सिस्टम-प्रदत्त गूंगा आवंटक [उपज] बेहतर प्रदर्शन के साथ ... ... सबसे सरल कस्टम आवंटकों, जो बहुत ही विशेष स्थितियों के लिए ट्यून किए गए हैं, केवल वे ही हैं जो लाभ प्रदान कर सकते हैं। " - Andrei Alexandrescu

अधिकांश प्रणाली allocators के बारे में सामान्य प्रयोजन संभाजक हो सकता है के रूप में रूप में अच्छा कर रहे हैं। यदि आपके पास एक बहुत ही विशिष्ट आवंटन पैटर्न है तो आप बेहतर केवल कर सकते हैं।

आमतौर पर, इस तरह के विशेष पैटर्न केवल कार्यक्रम के एक हिस्से पर लागू होते हैं, इस मामले में, कस्टम आवंटक को उस विशिष्ट हिस्से में लागू करना बेहतर होता है जो वैश्विक स्तर पर आवंटक को प्रतिस्थापित करने से लाभान्वित हो सकता है।

सी ++ आवंटक को चुनिंदा रूप से बदलने के कुछ तरीके प्रदान करता है। उदाहरण के लिए, आप एक एसटीएल कंटेनर को आवंटित कर सकते हैं या आप कक्षा को आधार पर कक्षा में हटा सकते हैं और कक्षा को हटा सकते हैं। ये दोनों आपको किसी भी हैक से अधिक बेहतर नियंत्रण देते हैं जो विश्व स्तर पर आवंटक को प्रतिस्थापित करता है।

ध्यान दें कि मॉलोक और फ्री को प्रतिस्थापित करने से ऑपरेटरों द्वारा उपयोग किए जाने वाले आवंटन को नए और हटाए जाने की आवश्यकता नहीं होगी। जबकि वैश्विक नए ऑपरेटर को आम तौर पर मॉलोक का उपयोग करके कार्यान्वित किया जाता है, ऐसा करने की कोई आवश्यकता नहीं होती है। इसलिए मॉलोक को प्रतिस्थापित करने से अधिकांश आवंटन प्रभावित नहीं हो सकते हैं।

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

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

सिस्टम आवंटकों को प्रतिस्थापित करने के लिए अधिकांश तकनीकें इन लाभों को जब्त करती हैं। कुछ मामलों में, वे स्मृति मांग भी बढ़ा सकते हैं (क्योंकि उन्हें संभवतः अन्य प्रक्रियाओं द्वारा उपयोग किए जाने वाले डीएलएल रनटाइम के साथ साझा नहीं किया जा सकता है)। वे कंपाइलर संस्करण, रनटाइम संस्करण, और यहां तक ​​कि ओएस संस्करण में बदलावों के चेहरे में बेहद नाजुक होते हैं। रनटाइम के tweaked संस्करण का उपयोग करने से आपके उपयोगकर्ताओं को ओएस विक्रेता से रनटाइम अपडेट के लाभ प्राप्त होने से रोकता है। जब आप एक कस्टम आवंटक को केवल उस कार्यक्रम के असाधारण भाग के लिए लागू करके लाभ प्राप्त कर सकते हैं, तो इससे लाभ क्यों प्राप्त हो सकता है?