प्रोटोटाइप के माध्यम से इसे बनाकर प्रोटोटाइप के माध्यम से परिभाषित तरीकों - वास्तव में एक प्रदर्शन अंतर?

Question

जावास्क्रिप्ट में, हमारे पास "कक्षा" बनाने और इसे सार्वजनिक कार्य करने के दो तरीके हैं।

विधि 1:

function MyClass() { 
    var privateInstanceVariable = 'foo'; 
    this.myFunc = function() { alert(privateInstanceVariable); } 
} 

विधि 2:

function MyClass() { } 

MyClass.prototype.myFunc = function() { 
    alert("I can't use private instance variables. :("); 
} 

मैं कई बार लोगों saying पढ़ा है कि का उपयोग कर सभी उदाहरणों समारोह का एक ही प्रति साझा रूप में नहीं बल्कि विधि 2 अधिक कुशल है प्रत्येक को अपना खुद का प्राप्त करने से। प्रोटोटाइप के माध्यम से कार्यों को परिभाषित करने के लिए एक बड़ा नुकसान है - यह निजी आवृत्ति चर के लिए असंभव बनाता है।

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

कोई अंतर्दृष्टि - या इससे भी बेहतर, असली दुनिया का अनुभव - दोनों के बीच प्रदर्शन अंतर के बारे में, बेहद सहायक होगा।

Answer 1

http://jsperf.com/prototype-vs-this

अपने तरीके की घोषणा के माध्यम से प्रोटोटाइप तेजी से होता है, लेकिन या नहीं, यह प्रासंगिक है बहस का मुद्दा है देखें।

यदि आपके ऐप में प्रदर्शन बाधा है तो यह ऐसा होने की संभावना नहीं है, जब तक कि आप कुछ मनमाने ढंग से एनीमेशन के प्रत्येक चरण पर 10000+ ऑब्जेक्ट्स को तुरंत चालू नहीं करते हैं।

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

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

Answer 2

संक्षेप में, गुणों/विधियों को बनाने के लिए विधि 2 का उपयोग करें जो सभी उदाहरण साझा करेंगे। वे "वैश्विक" होंगे और इसमें कोई भी बदलाव सभी मामलों में दिखाई देगा। उदाहरण विशिष्ट गुण/विधियों को बनाने के लिए विधि 1 का उपयोग करें।

मेरी इच्छा है कि मेरे पास बेहतर संदर्भ हो लेकिन अब this पर एक नज़र डालें। आप देख सकते हैं कि मैंने विभिन्न उद्देश्यों के लिए एक ही प्रोजेक्ट में दोनों विधियों का उपयोग कैसे किया।

उम्मीद है कि इससे मदद मिलती है। :)

Answer 3

जब आप बहुत सारे उदाहरण बना रहे हैं तो यह केवल एक फर्क पड़ता है। अन्यथा, सदस्य फ़ंक्शन को कॉल करने का प्रदर्शन दोनों मामलों में बिल्कुल समान है।

मैं jsperf पर एक टेस्ट केस बना लिया है इस प्रदर्शन करने के लिए:

http://jsperf.com/prototype-vs-this/10

Answer 4

आप इस पर विचार किया है नहीं हो सकता है, लेकिन वस्तु पर सीधे विधि डाल वास्तव में एक तरह से बेहतर है:

1. विधि आमंत्रण बहुत थोड़ा तेजी (jsperf) के बाद से प्रोटोटाइप श्रृंखला परामर्श किया जाना नहीं है टी हैं ओ विधि को हल करें।

हालांकि, गति अंतर लगभग नगण्य है।

1. तेज़ उदाहरणों बनाने के लिए (jsperf)
2. कम स्मृति

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

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

---

तरफ:

आप सही है कि यह प्रोटोटाइप पर अंदर तरीकों से निजी उदाहरण चर का उपयोग करने के असंभव है। तो मुझे लगता है कि आपको खुद से पूछना चाहिए कि क्या आप विरासत और प्रोटोटाइप का उपयोग करने के लिए वास्तव में निजी रूप से व्यक्तिगत रूप से निजी बनाने में सक्षम होने का महत्व रखते हैं? मैं व्यक्तिगत रूप से सोचता हूं कि चर को वास्तव में निजी बनाना महत्वपूर्ण नहीं है और केवल यह इंगित करने के लिए अंडरस्कोर उपसर्ग (उदाहरण के लिए, "this._myVar") का उपयोग करेगा, हालांकि वैरिएबल सार्वजनिक है, इसे निजी माना जाना चाहिए। उस ने कहा, ईएस 6 में, दोनों दुनिया दोनों के पास स्पष्ट रूप से एक तरीका है!

Answer 5

क्रोम के नए संस्करण में, यह .method prototype.method की तुलना में लगभग 20% तेज है, लेकिन नई वस्तु बनाना अभी भी धीमा है।

यदि आप हमेशा एक नया निर्माण करने के बजाय ऑब्जेक्ट का पुन: उपयोग कर सकते हैं, तो यह नई वस्तुओं को बनाने से 50% - 90% तेज हो सकता है। प्लस कोई कचरा संग्रहण, जो बहुत बड़ा है के लाभ:

http://jsperf.com/prototype-vs-this/59

Answer 6

इस उत्तर लापता अंक में भरने के जवाब के बाकी का एक विस्तार माना जाना चाहिए। व्यक्तिगत अनुभव और मानक दोनों शामिल हैं।

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

1. प्रोटोटाइप विरासत का उपयोग करना और निजी रूप से वस्तुओं को चिह्नित करने के लिए एक सम्मेलन डीबगिंग को आसान बनाता है क्योंकि आप कंसोल या डीबगर से आसानी से ऑब्जेक्ट ग्राफ़ को पार कर सकते हैं। दूसरी तरफ, इस तरह के एक सम्मेलन में कुछ हद तक कड़ी मेहनत होती है और दूसरों के लिए आपकी साइट पर अपनी स्क्रिप्ट पर बोल्ट करना आसान बनाता है। यह निजी कारणों की लोकप्रियता हासिल करने के कारणों में से एक है। यह सच सुरक्षा नहीं है बल्कि इसके बजाय प्रतिरोध जोड़ता है। दुर्भाग्य से बहुत से लोग अभी भी सोचते हैं कि यह सुरक्षित जावास्क्रिप्ट प्रोग्राम करने का एक वास्तविक तरीका है। चूंकि डिबगर्स वास्तव में अच्छे हो गए हैं, कोड obfuscation अपनी जगह लेता है। यदि आप सुरक्षा त्रुटियों की तलाश में हैं, जहां ग्राहक पर बहुत अधिक है, तो यह एक डिज़ाइन पैटर्न है जिसे आप देखना चाहते हैं।
2. एक सम्मेलन आपको छोटे झगड़े के साथ संरक्षित गुणों की अनुमति देता है। यह एक आशीर्वाद और अभिशाप हो सकता है। यह कुछ विरासत मुद्दों को कम करता है क्योंकि यह कम प्रतिबंधक है। आपको अभी भी टकराव का खतरा है या इस बात पर विचार करने के लिए संज्ञानात्मक भार बढ़ गया है कि किसी और संपत्ति का उपयोग किया जा सकता है। स्वयं को इकट्ठा करने वाली वस्तुएं आपको कुछ अजीब चीजें करने देती हैं जहां आप कई विरासत समस्याओं को प्राप्त कर सकते हैं लेकिन वे अपरंपरागत हो सकते हैं। मेरे मॉड्यूल में एक समृद्ध आंतरिक संरचना होती है जहां चीजों को तब तक नहीं खींचा जाता जब तक कार्यक्षमता की आवश्यकता नहीं होती है (साझा) या बाहरी रूप से आवश्यक होने तक खुलासा किया जाता है। कन्स्ट्रक्टर पैटर्न केवल टुकड़े टुकड़े वस्तुओं की तुलना में स्वयं निहित परिष्कृत मॉड्यूल बनाने के लिए नेतृत्व करता है। यदि आप चाहते हैं तो यह ठीक है। अन्यथा यदि आप अधिक पारंपरिक ओओपी संरचना और लेआउट चाहते हैं तो शायद मैं सम्मेलन द्वारा पहुंच को विनियमित करने का सुझाव दूंगा। मेरे उपयोग परिदृश्य में जटिल ओओपी अक्सर उचित नहीं होता है और मॉड्यूल चाल करता है।
3. यहां सभी परीक्षण न्यूनतम हैं। असली दुनिया के उपयोग में यह संभावना है कि मॉड्यूल अधिक जटिल होंगे जिससे हिट को परीक्षणों से बहुत अधिक संकेत मिलेगा। यह एक सामान्य चर है जिसमें कई विधियों के साथ काम करने के साथ आम बात है और उन तरीकों में से प्रत्येक पद्धति प्रारंभिकरण पर अधिक ओवरहेड जोड़ती है जिसे आप प्रोटोटाइप विरासत के साथ नहीं प्राप्त करेंगे। ज्यादातर मामलों में कोई फर्क नहीं पड़ता क्योंकि ऐसी वस्तुओं के केवल कुछ उदाहरण आसपास तैरते हैं हालांकि संचयी रूप से यह जोड़ सकता है।
4. एक धारणा है कि प्रोटोटाइप लुकअप प्रोटोटाइप लुकअप के कारण कॉल करने के लिए धीमे हैं। यह एक अनुचित धारणा नहीं है, मैंने इसे तब तक बनाया जब तक मैंने इसका परीक्षण नहीं किया। हकीकत में यह जटिल है और कुछ परीक्षणों से पता चलता है कि पहलू छोटा है। prototype.m = f, this.m = f और this.m = function... के बीच, पहले के पहले प्रदर्शन करने वाले पहले दो की तुलना में काफी बेहतर प्रदर्शन करता है। यदि अकेले प्रोटोटाइप लुकअप एक महत्वपूर्ण मुद्दा था तो आखिरी दो कार्य इसके बजाय पहले महत्वपूर्ण प्रदर्शन करेंगे। कैनरी के संबंध में कम से कम कुछ और अजीब चल रहा है। यह संभव कार्यों को अनुकूलित किया जाता है कि वे किस सदस्य हैं। प्रदर्शन विचारों की एक भीड़ खेल में आती है। आपके पास पैरामीटर पहुंच और चर पहुंच के लिए अंतर भी हैं।
5. मेमोरी क्षमता। यहां पर अच्छी तरह से चर्चा नहीं की गई है। एक धारणा है कि आप आगे बढ़ सकते हैं जो सच होने की संभावना है कि प्रोटोटाइप विरासत आमतौर पर अधिक स्मृति कुशल होगी और मेरे परीक्षणों के अनुसार यह सामान्य रूप से सामान्य है। जब आप अपने कन्स्ट्रक्टर में अपना ऑब्जेक्ट बनाते हैं तो आप यह मान सकते हैं कि प्रत्येक ऑब्जेक्ट में साझा किए जाने के बजाए प्रत्येक फ़ंक्शन का अपना उदाहरण होगा, अपने निजी गुणों के लिए एक बड़ा प्रॉपर्टी मैप होगा और संभवतः कन्स्ट्रक्टर स्कोप को भी खोलने के लिए कुछ ओवरहेड होगा। निजी क्षेत्र पर काम करने वाले कार्य अत्यंत और असमान रूप से स्मृति की मांग कर रहे हैं।मुझे लगता है कि कई परिदृश्यों में स्मृति में आनुपातिक अंतर CPU चक्रों में आनुपातिक अंतर से कहीं अधिक महत्वपूर्ण होगा।
6. मेमोरी ग्राफ। आप जीसी को अधिक महंगा बनाने वाले इंजन को भी जा सकते हैं। प्रोफाइलर्स इन दिनों जीसी में बिताए गए समय को दिखाते हैं। जब यह आवंटित करने और अधिक मुक्त करने की बात आती है तो यह केवल एक समस्या नहीं है। आप ट्रैवर्स और ऐसी चीजों के लिए एक बड़ा ऑब्जेक्ट ग्राफ़ भी बनायेंगे ताकि जीसी अधिक चक्र खा सके। यदि आप एक मिलियन ऑब्जेक्ट्स बनाते हैं और फिर उन्हें मुश्किल से स्पर्श करते हैं, तो इंजन के आधार पर यह आपके अपेक्षा से अधिक परिवेश प्रदर्शन प्रभाव डाल सकता है। मैंने साबित कर दिया है कि जब कम से कम वस्तुओं का निपटारा किया जाता है तो यह कम से कम जीसी रन बना देता है। यह स्मृति उपयोग के साथ एक सहसंबंध और जीसी को ले जाने का समय लगता है। हालांकि ऐसे मामले हैं जहां स्मृति की परवाह किए बिना समय समान है। यह इंगित करता है कि ग्राफ मेकअप (संकेतक की परतें, आइटम गिनती, आदि) का अधिक प्रभाव पड़ता है। ऐसा कुछ ऐसा नहीं है जो भविष्यवाणी करना हमेशा आसान हो।
7. बहुत से लोग बड़े पैमाने पर जंजीर प्रोटोटाइप का उपयोग नहीं करते हैं, स्वयं को शामिल किया गया है मुझे प्रवेश करना है। प्रोटोटाइप चेन सिद्धांत में महंगा हो सकता है। कोई होगा लेकिन मैंने लागत को माप नहीं लिया है। यदि आप इसके बजाय पूरी तरह से कन्स्ट्रक्टर में अपनी ऑब्जेक्ट्स बनाते हैं और उसके बाद विरासत की एक श्रृंखला होती है क्योंकि प्रत्येक कन्स्ट्रक्टर स्वयं पर एक मूल रचनाकार कहता है, सिद्धांत विधि में उपयोग बहुत तेज होना चाहिए। दूसरी तरफ यदि आप मायने रखते हैं तो समकक्ष को पूरा कर सकते हैं (जैसे कि पूर्वजों की श्रृंखला के प्रोटोटाइप को फटकारना) और यदि आपको वास्तव में इसकी ज़रूरत है तो आपको हैऑनप्रोपर्टी, शायद उदाहरण आदि जैसी चीजों को तोड़ने में कोई फर्क नहीं पड़ता। प्रदर्शन की हैक की बात आती है जब किसी भी मामले में जब आप सड़क पर उतर जाते हैं तो चीजें जटिल हो जाती हैं। आप शायद उन चीजों को खत्म कर देंगे जो आपको नहीं करना चाहिए।
8. कई लोग सीधे आपके द्वारा प्रस्तुत किए गए दृष्टिकोण का उपयोग नहीं करते हैं। इसके बजाए वे अज्ञात वस्तुओं का उपयोग करके अपनी खुद की चीजें बनाते हैं, जिस तरह से विधि साझा करना (उदाहरण के लिए मिश्रित)। मॉड्यूल और ऑब्जेक्ट्स व्यवस्थित करने के लिए कई रणनीतियां भी हैं जो अपनी रणनीतियों को लागू करती हैं। ये भारी सम्मेलन आधारित कस्टम दृष्टिकोण हैं। अधिकांश लोगों के लिए और आपके लिए आपकी पहली चुनौती प्रदर्शन के बजाए संगठन होना चाहिए। यह प्रायः जटिल है कि जावास्क्रिप्ट अधिक स्पष्ट ओओपी/नेमस्पेस/मॉड्यूल समर्थन के साथ चीजों या प्लेटफॉर्म बनाम चीजों को प्राप्त करने के कई तरीकों को प्रदान करता है। जब प्रदर्शन की बात आती है तो मैं पहले और सबसे प्रमुख प्रमुख नुकसान से बचने के लिए कहूंगा।
9. एक नया प्रतीक प्रकार है जो निजी चर और विधियों के लिए काम करना चाहिए। इसका उपयोग करने के कई तरीके हैं और यह प्रदर्शन और पहुंच से संबंधित कई प्रश्न उठाता है। मेरे परीक्षणों में प्रतीकों का प्रदर्शन अन्य सभी की तुलना में बहुत अच्छा नहीं था, लेकिन मैंने कभी उनका परीक्षण नहीं किया।

अस्वीकरण:

1. वहाँ प्रदर्शन के बारे में विचार-विमर्श के बहुत सारे हैं और वहाँ हमेशा उपयोग परिदृश्यों और इंजन परिवर्तन के रूप में इस के लिए एक स्थायी रूप से सही जवाब नहीं है। हमेशा प्रोफाइल करें लेकिन हमेशा एक से अधिक तरीकों से मापें क्योंकि प्रोफाइल हमेशा सटीक या भरोसेमंद नहीं होते हैं। ऑप्टिमाइज़ेशन में महत्वपूर्ण प्रयास से बचें जब तक कि निश्चित रूप से एक प्रदर्शनकारी समस्या न हो।
2. स्वचालित परीक्षण में संवेदनशील क्षेत्रों के प्रदर्शन प्रदर्शन और ब्राउज़र अपडेट होने पर चलाने के लिए यह संभवतः बेहतर है।
3. कभी-कभी बैटरी जीवन के मामलों के साथ-साथ अवधारणात्मक प्रदर्शन को याद रखें। उस पर एक अनुकूल संकलक चलाने के बाद सबसे धीमी समाधान तेजी से हो सकता है (आईई, एक संकलक के पास बेहतर विचार हो सकता है जब प्रतिबंधित स्कोप चर को सम्मेलन द्वारा निजी रूप से चिह्नित गुणों से एक्सेस किया जाता है)। बैकएंड पर विचार करें जैसे node.js. आपको ब्राउजर पर अक्सर मिलने की तुलना में बेहतर विलंबता और थ्रूपुट की आवश्यकता हो सकती है। अधिकांश लोगों को इन चीजों के बारे में चिंता करने की आवश्यकता नहीं होती है, जैसे पंजीकरण फॉर्म के लिए सत्यापन की तरह, लेकिन विभिन्न परिदृश्यों की संख्या जहां ऐसी चीजें हो सकती हैं, बढ़ती जा रही है।
4. परिणाम को जारी रखने के लिए आपको स्मृति आवंटन ट्रैकिंग टूल से सावधान रहना होगा।कुछ मामलों में जहां मैं वापस नहीं आया और डेटा को जारी रखता हूं, इसे पूरी तरह से अनुकूलित किया गया था या नमूना दर तत्काल/अप्रतिबंधित के बीच पर्याप्त नहीं थी, जिससे मुझे अपने सिर को खरोंच कर दिया गया कि कैसे एक सरणी शुरू हुई और 3.4KiB के रूप में पंजीकृत एक मिलियन से भरा आवंटन प्रोफाइल में।
5. ज्यादातर मामलों में असली दुनिया में वास्तव में एप्लिकेशन को अनुकूलित करने का एकमात्र तरीका यह है कि इसे पहले स्थान पर लिखना ताकि आप इसे माप सकें। सैकड़ों कारक हैं जो किसी भी परिदृश्य में हजारों नहीं होने पर खेल सकते हैं। इंजन उन चीजों को भी करते हैं जो असमान या गैर-रैखिक प्रदर्शन विशेषताओं का कारण बन सकते हैं। यदि आप किसी कन्स्ट्रक्टर में फ़ंक्शंस को परिभाषित करते हैं, तो वे तीर फ़ंक्शन या पारंपरिक हो सकते हैं, प्रत्येक कुछ स्थितियों में अलग-अलग व्यवहार करता है और मुझे अन्य फ़ंक्शन प्रकारों के बारे में कोई जानकारी नहीं है। कक्षाएं प्रोटोटाइप कन्स्ट्रक्टर के प्रदर्शन के रूप में समान व्यवहार नहीं करती हैं जो समकक्ष होना चाहिए। आपको बेंचमार्क के साथ भी सावधान रहना होगा। प्रोटोटाइप कक्षाएं विभिन्न तरीकों से स्थगित प्रारंभिकरण हो सकती हैं, खासकर अगर आपके गुणों को भी प्रोटोटाइप किया जाता है (सलाह, नहीं)। इसका मतलब है कि आप प्रारंभिक लागत को कम कर सकते हैं और पहुंच/संपत्ति उत्परिवर्तन लागत को बढ़ा सकते हैं। मैंने प्रगतिशील अनुकूलन के संकेत भी देखे हैं। इन मामलों में मैंने ऑब्जेक्ट्स के उदाहरणों के साथ एक बड़ी सरणी भर दी है जो कि समान हैं और जैसे ही ऑब्जेक्ट्स की संख्या बढ़ जाती है, वैसे ही ऑब्जेक्ट्स को उस बिंदु तक स्मृति के लिए अनुकूलित रूप से अनुकूलित किया जाता है जहां शेष समान होता है। यह भी संभव है कि उन अनुकूलन सीपीयू प्रदर्शन को भी महत्वपूर्ण रूप से प्रभावित कर सकें। ये चीजें न केवल आपके द्वारा लिखे गए कोड पर निर्भर होती हैं, बल्कि वस्तुओं की संख्या, वस्तुओं के बीच भिन्नता, आदि जैसे