मैनुअल मेमोरी प्रबंधन की तुलना में कचरा संग्रह का प्रदर्शन तेज है


23

मैंने कई स्थानों पर पढ़ा है (हेक, मैंने खुद भी लिखा है) ताकि कचरा संग्रह (सैद्धांतिक रूप से) मैन्युअल मेमोरी प्रबंधन की तुलना में तेज हो सके

हालाँकि, बताने से ज्यादा दिखाना कठिन है।
मैंने वास्तव में कोड का कोई टुकड़ा नहीं देखा है जो कार्रवाई में इस प्रभाव को प्रदर्शित करता है।

क्या किसी के पास (या पता है कि मुझे कहां मिल सकता है) कोड जो इस प्रदर्शन लाभ को प्रदर्शित करता है?


5
जीसी के साथ समस्या यह है कि अधिकांश कार्यान्वयन नियतात्मक नहीं हैं, इसलिए 2 रन में काफी भिन्न परिणाम हो सकते हैं, यह उल्लेख नहीं करने के लिए कि तुलना करने के लिए सही चर को अलग करना मुश्किल है
शाफ़्ट फ्रीक

@ratchetfreak: यदि आप किसी ऐसे उदाहरण के बारे में जानते हैं जो केवल 70% अधिक तेज (कहते हैं) है, तो यह मेरे साथ भी ठीक है। कम से कम थ्रूपुट के संदर्भ में दोनों की तुलना करने का कोई तरीका होना चाहिए (विलंबता शायद काम नहीं करेगी)।
मेहरदाद

1
खैर, यह थोड़ा मुश्किल है क्योंकि आप हमेशा जो कुछ भी कर सकते हैं वह जीसी को एक बढ़त देता है जो आपने मैन्युअल रूप से किया था। शायद इसे "मानक" मैनुअल मेमोरी मैनेजमेंट टूल्स (मॉलोक () / फ्री (), स्वामित्व वाले पॉइंटर्स, रीफोकाउंट के साथ साझा किए गए पॉइंटर्स, कमजोर पॉइंटर्स, कोई कस्टम एलोकेटर) तक सीमित रखना बेहतर है? या, यदि आप कस्टम आवंटनकर्ताओं की अनुमति देते हैं (जो अधिक यथार्थवादी या कम यथार्थवादी हो सकते हैं, तो आप किस प्रकार के प्रोग्रामर को मानते हैं, इसके आधार पर, उन आवंटनकर्ताओं में लगाए गए प्रयासों पर प्रतिबंध लगाएं। अन्यथा, मैनुअल रणनीति "प्रतिलिपि इस मामले में जीसी क्या करती है" हमेशा कम से कम जीसी जितनी तेज होती है।

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

1
@ मैं: यह ठीक है। देखें कि मैंने सवाल क्यों पूछा? यह मेरे प्रश्न का संपूर्ण बिंदु था - लोग हर तरह के स्पष्टीकरण के साथ आते हैं जो समझ में आना चाहिए , लेकिन हर कोई तब लड़खड़ा जाता है जब आप उनसे एक प्रदर्शन प्रदान करने के लिए कहते हैं जो साबित करता है कि वे व्यवहार में सही हैं। इस सवाल का पूरा बिंदु एक बार और सभी के लिए था कि यह वास्तव में व्यवहार में हो सकता है।
मेहरदाद

जवाबों:


26

Http://blogs.msdn.com/b/ricom/archive/2005/05/10/416151.aspx देखें और सभी लिंक का अनुसरण करें रीको मरिअनी बनाम रेमंड चेन (माइक्रोसॉफ्ट में दोनों बहुत ही सक्षम प्रोग्रामर) को देखें। । रेमंड अप्रबंधित में सुधार करेगा, रीको प्रबंधित लोगों में एक ही चीज का अनुकूलन करके जवाब देगा।

अनिवार्य रूप से शून्य अनुकूलन प्रयास के साथ, प्रबंधित संस्करण मैन्युअल की तुलना में कई गुना तेजी से शुरू हुए। आखिरकार मैनुअल ने बाजी मार ली, लेकिन केवल इस स्तर पर अनुकूलन करके कि अधिकांश प्रोग्रामर नहीं जाना चाहेंगे। सभी संस्करणों में, मैनुअल का मेमोरी उपयोग प्रबंधित की तुलना में बेहतर था।


+1 कोड के साथ एक वास्तविक उदाहरण का हवाला देने के लिए :) यद्यपि C ++ कंस्ट्रक्शन (जैसे swap) का उचित उपयोग उतना कठिन नहीं है, और शायद आपको वहां आसानी से प्रदर्शन-वार मिलेगा ...
मेहरदाद

5
आप प्रदर्शन पर रेमंड चेन को पछाड़ने में सक्षम हो सकते हैं। मुझे विश्वास है कि मैं तब तक नहीं रह सकता जब तक कि वह बीमार होने के कारण इससे बाहर नहीं निकल जाता, मैं कई बार कड़ी मेहनत कर रहा हूं, और मैं भाग्यशाली रहा। मुझे नहीं पता कि उसने आपके द्वारा चुने गए समाधान का चयन क्यों नहीं किया। मुझे यकीन है कि उसके पास इसके कारण थे
btilly

मैंने रेमंड के कोड को यहां कॉपी किया , और तुलना करने के लिए, मैंने यहां अपना संस्करण लिखा । जिप फाइल जिसमें टेक्स्ट फाइल है वह यहां है । मेरे कंप्यूटर पर, मेरा 14 ms में और Raymond 21 ms में चलता है। जब तक मैंने कुछ गलत नहीं किया (जो संभव है), उसका 215-लाइन कोड मेरे 48-लाइन कार्यान्वयन की तुलना में 50% धीमा है, यहां तक ​​कि मेमोरी-मैप की गई फ़ाइलों या कस्टम मेमोरी पूल (जो उसने उपयोग किया था) का उपयोग किए बिना । मेरा # C संस्करण के रूप में आधा लंबा है। क्या मैंने यह गलत किया, या आप एक ही बात का पालन करते हैं?
मेहरदाद

1
@ मेहरदाद ने इस लैपटॉप पर जीसीसी की एक पुरानी प्रति खींचकर मुझे बताया कि न तो आपका कोड और न ही उसका संकलन होगा, अकेले ही इसके साथ कुछ भी करने दें। तथ्य यह है कि मैं विंडोज पर नहीं हूँ संभावना है कि बताते हैं। लेकिन मान लेते हैं कि आपके नंबर और कोड सही हैं। क्या वे एक दशक पुराने कंपाइलर और कंप्यूटर पर समान प्रदर्शन करते हैं? (जब ब्लॉग लिखा गया था तो देखें।) हो सकता है, शायद नहीं। मान लीजिए कि वे हैं, कि वह (एक सी प्रोग्रामर होने के नाते) सी + + का ठीक से उपयोग करना नहीं जानता, आदि हम किस चीज से बचे हैं?
btilly

1
हम एक उचित C ++ प्रोग्राम के साथ बचे हैं, जिसे प्रबंधित मेमोरी में ट्रांसलेट किया जा सकता है। लेकिन जहां सी ++ संस्करण को अनुकूलित किया जा सकता है और दूर तक फैलाया जा सकता है। जो कि हम सभी समझौते में हैं वह सामान्य पैटर्न है जो हमेशा होता है जब प्रबंधित कोड अप्रबंधित से तेज होता है। हालाँकि हमारे पास अभी भी एक अच्छे प्रोग्रामर से उचित कोड का एक ठोस उदाहरण है जो एक प्रबंधित संस्करण में तेज था।
btilly

5

अंगूठे का नियम यह है कि मुफ्त लंच नहीं होते हैं।

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

जीसी मैन्युअल मेमोरी प्रबंधन का एक विशेष मामला है

मैन्युअल रूप से बेहतर प्रदर्शन पाने के लिए यह बहुत अधिक काम या अधिक त्रुटि हो सकती है लेकिन यह एक अलग कहानी है।


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

2
1) मुझे टिप्पणी करने के लिए विशिष्ट कोड देखना होगा, लेकिन अगर कोड में हाथ से लिखे गए आवंटन / अवरोधक तेज हैं तो हाथ से लिखे कोडांतरक का उपयोग करें। निश्चित नहीं है कि जीसी के साथ क्या करना है। 2) यहां एक नज़र डालें: stackoverflow.com/a/9814654/441099 बिंदु यह नहीं है कि क्या कुछ गैर-जीसी भाषा आपके लिए पूंछ पुनरावृत्ति उन्मूलन कर सकती है। मुद्दा यह है कि आप अपने कोड को तेज या तेज होने के लिए बदल सकते हैं। क्या कुछ विशिष्ट भाषा के संकलक आपके लिए स्वचालित रूप से ऐसा कर सकते हैं। एक कम पर्याप्त अमूर्त में आप हमेशा अपनी इच्छा के अनुसार ऐसा कर सकते हैं।
गाइ सिर्टन

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

3

एक कृत्रिम स्थिति का निर्माण करना आसान है जहां जीसी मैन्युअल तरीकों की तुलना में असीम रूप से अधिक कुशल है - बस व्यवस्था करें कि कचरा कलेक्टर के लिए केवल एक "रूट" है, और यह कि सब कुछ कचरा है, इसलिए जीसी चरण तुरंत पूरा हो गया है।

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

व्यावहारिक कार्यक्रमों के लिए, कचरा संग्रह के साथ भाषाओं में लिखा गया है, कचरा संग्रह का लाभ गति नहीं है, बल्कि शुद्धता और सरलता है।


यदि एक कृत्रिम उदाहरण का निर्माण करना आसान है, तो क्या आप एक साधारण दिखावा करेंगे?
मेहरदाद

1
@ मेहरदाद उन्होंने एक सरल व्याख्या की। एक प्रोग्राम लिखें जहां जीसी संस्करण बाहर निकलने से पहले कचरा चलाने में विफल रहता है। मैन्युअल मेमोरी प्रबंधित संस्करण धीमा हो जाएगा क्योंकि यह स्पष्ट रूप से ट्रैकिंग और मुफ्त सामान था।
btilly

3
@ बीटीली: "एक प्रोग्राम लिखें जहां जीसी संस्करण बाहर निकलने से पहले कचरा चलाने में विफल रहता है।" ... पहली जगह में कचरा संग्रह करने में विफल रहने के कारण एक कामकाजी जीसी की कमी के कारण एक मेमोरी लीक है , न कि जीसी की उपस्थिति के कारण प्रदर्शन में सुधार ! abort()प्रोग्राम से बाहर निकलने से पहले C ++ में कॉल करना पसंद है। यह एक व्यर्थ की तुलना है; आप कचरा संग्रहण भी नहीं कर रहे हैं, आप सिर्फ मेमोरी लीक होने दे रहे हैं। आप यह नहीं कह सकते कि कचरा संग्रहण तेज़ (या धीमा) है यदि आप कचरा-संग्रह शुरू नहीं कर रहे हैं ...
मेहरदाद

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

3
@ मेहरदाद ऐसा नहीं है। परिदृश्य यह है कि GC संस्करण उस दहलीज पर हिट करने के लिए कभी नहीं हुआ, जिस पर उसने एक रन बनाया होगा, न कि यह एक अलग डेटा सेट पर सही ढंग से प्रदर्शन करने में विफल रहा होगा। यह जीसी संस्करण के लिए बहुत अच्छा होने वाला है, हालांकि अंतिम प्रदर्शन का अच्छा अनुमानक नहीं है।
btilly

2

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

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


2

तेजी से संदिग्ध है। हालाँकि, यह अल्ट्रा-फास्ट, अगोचर या तेज़ हो सकता है अगर यह हार्डवेयर समर्थित हो। कुछ समय पहले LISP मशीनों के लिए इस तरह के डिजाइन थे। एक ने जीसी को हार्डवेयर के मेमोरी सबसिस्टम में बनाया, जैसे कि मुख्य सीपीयू को पता नहीं था कि यह वहां है। बाद के कई डिजाइनों की तरह, जीसी मुख्य प्रोसेसर के साथ समवर्ती रूप से दौड़ा या ठहराव की कोई आवश्यकता नहीं थी। एक अधिक आधुनिक डिजाइन अज़ुल सिस्टम वेगा 3 मशीनें हैं जो जेवीएम का उपयोग किए गए उद्देश्य-निर्मित प्रोसेसर और एक पॉज़लेस जीसी की तुलना में तेजी से जावा कोड तरीके से चलती हैं। यदि आप जानना चाहते हैं कि जीसी (या जावा) कितना तेज हो सकता है।


2

मैंने इस पर काफी काम किया है और इसका कुछ वर्णन यहां किया है । मैंने C ++ में Boehm GC को बेंचमार्क किया, mallocलेकिन उपयोग नहीं कर रहा है, बल्कि मुक्त, आवंटित और उपयोग कर मुक्त कर रहा है freeऔर एक कस्टम-निर्मित मार्क-क्षेत्र GC लिखा है, जो C ++ सभी बनाम OCaml के स्टॉक GC में लिस्ट-आधारित n-quever solver चल रहा है। OCaml की GC सभी मामलों में तेज थी। C ++ और OCaml प्रोग्राम को समान क्रम में समान आवंटन करने के लिए जानबूझकर लिखा गया था।

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

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


+1 धन्यवाद। हम बेंचमार्क कोड कहां देख और चला सकते हैं?
मेहरदाद

कोड जगह के बारे में बिखरा हुआ है। मैंने यहाँ मार्क-क्षेत्र संस्करण पोस्ट किया है: group.google.com/d/msg/…
जॉन हैरोप

1
वहाँ दोनों थ्रेड सुरक्षित और असुरक्षित के लिए परिणाम हैं।
जॉन हैरोप

1
@ मेहरदाद: "क्या आपने त्रुटि के ऐसे संभावित स्रोतों को समाप्त कर दिया है?"। हाँ। OCaml के पास बहुत सरल संकलन मॉडल है जिसमें कोई भी विश्लेषण नहीं किया गया है जैसे कि भागने का विश्लेषण। OCaml के क्लोजर का प्रतिनिधित्व वास्तव में C ++ समाधान की तुलना में काफी धीमा है, इसलिए इसे वास्तव List.filterमें C ++ की तरह कस्टम का उपयोग करना चाहिए । लेकिन, हां, आप निश्चित रूप से काफी सही हैं कि कुछ आरसी संचालन को समाप्त किया जा सकता है। हालाँकि, मुझे सबसे बड़ी समस्या यह लगती है कि बड़े औद्योगिक कोड आधारों पर लोगों के पास इस तरह के अनुकूलन करने का समय नहीं है।
जॉन हैरोप

2
हाँ बिल्कुल। लिखने का कोई अतिरिक्त प्रयास नहीं, लेकिन कोड लिखना C ++ के साथ अड़चन नहीं है। कोड को बनाए रखना है। इस तरह की आकस्मिक जटिलता के साथ कोड बनाए रखना एक बुरा सपना है। अधिकांश औद्योगिक कोड आधार कोड की लाखों लाइनें हैं। आप बस उससे निपटना नहीं चाहते हैं। मैंने देखा है कि लोगों ने सब कुछ shared_ptrबदलकर सिर्फ कंसीलर बग्स को ठीक किया है। कोड बहुत धीमा है लेकिन, हे, अब यह काम करता है।
जॉन हैरोप

-1

इस तरह के उदाहरण के लिए जरूरी है कि एक खराब मैनुअल मेमोरी आवंटन योजना हो।

सबसे अच्छा कचरा कलेक्टर मान लें GC। इसमें आंतरिक रूप से मेमोरी आवंटित करने के तरीके हैं, यह निर्धारित करते हैं कि मेमोरी को क्या मुक्त किया जा सकता है, और अंत में इसे मुक्त करने के तरीके। इन सबको मिलाकर कम समय लगता है GC; कुछ समय अन्य तरीकों में बिताया जाता है GC

अब एक मैनुअल आवंटनकर्ता पर विचार करें जो समान आवंटन तंत्र का उपयोग करता है GC, और जिसकी free()कॉल बस स्मृति को उसी विधि से मुक्त करने के लिए सेट करती है GC। इसमें स्कैन चरण नहीं है, और न ही इसके कोई अन्य तरीके हैं। यह जरूरी कम समय लगता है।


2
एक कचरा-संग्राहक अक्सर कई वस्तुओं को मुक्त कर सकता है, स्मृति को एक के बाद एक उपयोगी स्थिति में रखने के बिना। एक निश्चित मानदंड को पूरा करने वाली सभी वस्तुओं को एक सरणी-सूची से हटाने के कार्य पर विचार करें। N- आइटम सूची से किसी एक आइटम को निकालना O (N) है; N की सूची से M आइटम हटा रहा है, एक समय में O (M * N) है। हालांकि, सूची के माध्यम से एकल पास में एक कसौटी पर खरा उतरने वाली सभी वस्तुओं को हटाना, ओ (1) है।
सुपरैट

@ सुपरफ़ैट: freeबैचों को भी एकत्रित कर सकता है। (और निश्चित रूप से सभी मदों को हटाने के लिए एक कसौटी को पूरा करना अभी भी ओ (एन) है, यदि केवल सूची ट्रैवर्सल के कारण ही हो)
एमएसलटर्स

एक कसौटी पर खरा उतरने वाली सभी वस्तुओं को हटाना कम से कम हे (एन) है। आप सही हैं कि freeबैच-कलेक्ट मोड में काम कर सकते हैं यदि प्रत्येक मेमोरी आइटम में एक झंडा जुड़ा हुआ है, हालांकि जीसी अभी भी कुछ स्थितियों में आगे आ सकता है। यदि किसी के पास M सन्दर्भ है, जो N चीजों के एक सेट से L विशिष्ट वस्तुओं की पहचान करता है, तो हर संदर्भ को हटाने का समय, जिसका कोई संदर्भ मौजूद नहीं है और शेष को O (N) के बजाय O (M) है। यदि किसी के पास अतिरिक्त जगह उपलब्ध है, तो स्केलिंग स्थिरांक काफी छोटा हो सकता है। इसके अलावा, एक गैर-स्कैनिंग जीसी सिस्टम में कॉम्पैक्टेशन की आवश्यकता होती है ...
सुपरकैट

@ सुपरकैट: खैर, यह निश्चित रूप से ओ (1) नहीं है क्योंकि पहली टिप्पणी में आपका अंतिम वाक्य है।
एमएसलटर्स

1
@MSalters: "और क्या एक नियतिवादी योजना को नर्सरी होने से रोक देगा?"। कुछ भी तो नहीं। OCaml का ट्रेसिंग कचरा संग्राहक नियतात्मक है और नर्सरी का उपयोग करता है। लेकिन यह "मैनुअल" नहीं है और मुझे लगता है कि आप "निर्धारक" शब्द का दुरुपयोग कर रहे हैं।
जॉन हैरोप
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.