मैं इस प्रश्न के सिर्फ एक तरफ विषय को संबोधित करना चाहता था, लेकिन एएए-प्रकार गेम इंजन के निम्न स्तर, प्रदर्शन-महत्वपूर्ण पहलुओं को बनाने के लिए कचरा संग्रह आवश्यक नहीं है। वास्तव में, वस्तुओं के लिए उस तरह के संदर्भ और संग्रह प्रणाली से परहेज करना सहायक है। आप मेमोरी में भी उपयोगकर्ता-परिभाषित प्रकारों को संयोजित करना चाहते हैं और कैश में आसन्न वस्तुओं को फिट करना चाहते हैं।
आवधिक अंतराल पर कचरा इकट्ठा करने और स्मृति में बिखरने वाली वस्तुओं के प्रदर्शन के मुद्दों के अलावा, गेम बर्दाश्त नहीं कर सकते अपने थोक संसाधनों के साथ रिसाव हो, और कचरा कलेक्टर वहां चीजों में बाधा डालता है। हां, मैंने अभी कहा है कि जीसी लीक से बचने की क्षमता में बाधा डालता है।
कचरा संग्रह संसाधन रिसाव के खिलाफ चांदी की गोली नहीं है।
जैसा कि लगता है कि प्रतिद्वंद्वी के रूप में प्रतिद्वंद्वी के रूप में, आज वहां सबसे कमजोर ऐप्स देखें: जिन लोगों का आप उनका उपयोग करते हैं, उतना अधिक स्मृति उपयोग बढ़ता जा रहा है। आम तौर पर वे सी या सी ++ अनुप्रयोग नहीं हैं। सी/सी ++ अनुप्रयोग दुर्घटनाग्रस्त होने के लिए कुख्यात हो सकते हैं, लेकिन लीक करने के लिए इतना नहीं। उन रिसाव वाले लोगों को अक्सर कचरा संग्रह वाली भाषाओं में प्रोग्राम किया जाता है।
उदाहरण के लिए, फ़्लैश गेम्स लें। वहां बहुत से लोग हैं, न केवल पूरे शौकिया सॉफ़्टवेयर का उपयोग करते हैं, जो अधिक से अधिक संसाधनों का उपयोग करते हैं और जितना अधिक आप खेल खेलते हैं उतना धीमा और धीमा हो जाते हैं, जिससे आप कभी-कभी गेम को तेज़ी से प्राप्त करने के लिए अपने ब्राउज़र को पुनरारंभ कर सकते हैं। फिर भी उन्हें एक्शनस्क्रिप्ट में कोड किया गया है, एक ऐसी भाषा जिसमें कचरा संग्रह है।
सिद्धांत में कचरा संग्रह लीक को कम करना चाहिए। व्यावहारिक रूप से, यह अक्सर अधिक महंगा और कठिन-से-अलग तार्किक रिसाव के बदले में सस्ता और आसान-से-ठीक-और-ठीक भौतिक रिसाव (जो मैं इस स्ट्रिंग को मिटाना भूल गया) को समाप्त करता है (ओह, तर्क का तर्क सिस्टम पूरे गेम बंद होने तक भारी संसाधनों को घूमने का कारण बनता है)।
ऐसा इसलिए है क्योंकि जीसी भाषा में, यदि आप किसी नए संसाधन, R के साझा स्वामित्व को बनाना चाहते हैं, तो आपको बस एक अन्य ऑब्जेक्ट, A में एक हैंडल/संदर्भ स्टोर करना है। B और CR पर एक हैंडल स्टोर भी कर सकता है, और अब R में तीन मालिक हैं और केवल तीन ही स्वामियों को संदर्भ जारी करने पर ही मुक्त किया जाएगा। उपयोगकर्ता केवल A स्टोर्स के साथ देखता है और काम करता है, इसलिए गेम लॉजिक में से R को समय-समय पर हटा दिया जाता है, लेकिन इसके संदर्भ B और C चुपचाप जारी करते हैं जो कोड रिलीज़ करना भूल गया।सी/सी ++ में, B और C में लटकते सूचक वास्तव में बेहतर हो सकते हैं, क्योंकि यह प्ले परीक्षण के दौरान तुरंत पता लगाने योग्य और सुधार योग्य समस्या का कारण बनता है, जहां डेवलपर एक डीबगर चलाने वाला व्यक्ति बहुत जल्दी स्पॉट करेगा और समस्या को ठीक करेगा। जीसी भाषा में, यह पता लगाना बेहद मुश्किल है और कार्यक्रम क्रैश नहीं होने पर, यह बड़ा समय लीक करना शुरू कर सकता है।
तो जीसी निश्चित रूप से लटकने वाले पॉइंटर्स से बचाता है, लेकिन अगर सी/सी ++ में कुछ लटक रहा होता और जीसी भाषा में लटकता नहीं होता है, तो यह एक जीसी भाषा में एक तार्किक संसाधन रिसाव है और सी/सी ++ में एक सीजीएफॉल्ट है । एक और तरीका रखो, जीसी एक्सचेंज उन संसाधनों को लटकाने के लिए पॉइंटर्स को लटकता है जो हमेशा के लिए घूमते हैं। यह आदान-प्रदान करता है कि एक मूक रिसाव में एक चमकदार दुर्घटना क्या होगी जो खोज करने के लिए एक डिबगिंग दुःस्वप्न हो सकती है (और उत्पाद को जारी करने के बाद भी अनजान हो सकती है)। तो ऐसे गेम की तरह जो बड़े पैमाने पर, गतिशील दुनिया और ग्राफिक्स और भौतिकी वस्तुओं को बना रहा है और इतने आगे और संभवतः प्रत्येक फ्रेम पर, तार्किक संसाधन लीक एक बड़ा सौदा है।
कचरा संग्रह सबसे अच्छा है जब संसाधन रिसाव एक बड़ा सौदा नहीं है।
यह पिछला परिदृश्य दुर्भाग्यवश जीसी का उपयोग कर बड़े पैमाने पर टीम पर्यावरण में बहुत आम है, खासकर यदि हर प्रोग्रामर कचरा संग्रह के नुकसान और कमजोर संदर्भों की मजबूत आवश्यकता से बहुत सावधान नहीं है। तो जीसी जरूरी नहीं है कि गेम बनाने के लिए लाभ के रूप में उद्धरण दें, जब तक कि आप केवल उच्चतम स्तर के मानव तर्क के बारे में बात नहीं कर रहे हों। निचले स्तर, नाज़ुक प्रणाली तर्क जो लगातार संसाधनों को बनाने और एक्सेस करने और नष्ट करने के लिए होता है, आमतौर पर इसके बिना लीक से बचने के मामले में भी बेहतर किराया जा रहा है।
एलडब्ल्यूजेजीएल, इसकी एक महान जावा ग्राफिक्स लाइब्रेरी को देखने का प्रयास करें। यह काफी हाल ही में है, हालांकि, अगर स्मृति सेवा करता है। –