क्या Microsoft खेल विकास के लिए C # गुणों का उपयोग करने की अनुशंसा करता है?

26

मुझे लगता है कि कभी-कभी आपको गुणों की आवश्यकता होती है, जैसे:

public int[] Transitions { get; set; }

या:

[SerializeField] private int[] m_Transitions;
public int[] Transitions { get { return m_Transitions; } set { m_Transitions = value; } }

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

क्या मैं सार्वजनिक क्षेत्रों का उपयोग नहीं करने के लिए विज़ुअल स्टूडियो के सुझावों की लगातार अनदेखी करने का अधिकार हूं? (ध्यान दें कि हम int Foo { get; private set; }वहाँ उपयोग करते हैं जहाँ इच्छित उपयोग दिखाने में एक फायदा है।)

मुझे पता है कि समय से पहले अनुकूलन खराब है, लेकिन जैसा कि मैंने कहा, खेल के विकास में आप कुछ धीमी गति से नहीं बनाते हैं जब एक समान प्रयास इसे तेज कर सकता है।

unity performance optimization

— piojo
स्रोत

34

हमेशा "धीमी" होने पर विश्वास करने से पहले एक प्रोफाइलर के साथ सत्यापित करें। मुझे बताया गया कि कुछ "धीमा" था और प्रोफाइलर ने मुझे बताया कि इसे आधे सेकंड में खोने के लिए 500,000,000 बार निष्पादित करना पड़ा। जैसा कि यह एक फ्रेम में कुछ सौ से अधिक बार निष्पादित नहीं करेगा, मैंने फैसला किया कि यह अप्रासंगिक था।

— Almo

5

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

— hegel5000

3

@ अलमो क्या आप 10,000 अलग-अलग जगहों पर होने वाले ऑपरेशन के लिए वही तर्क लागू करते हैं? क्योंकि वह क्लास मेंबर एक्सेस है। तार्किक रूप से आपको यह पसंद करने की लागत को तय करने से पहले प्रदर्शन लागत को 10K से गुणा करना चाहिए। और 0.5 एमएस अंगूठे का एक बेहतर नियम है जब आपके खेल का प्रदर्शन बर्बाद हो जाएगा, न कि आधे सेकंड में। आपकी बात अब भी कायम है, हालांकि मुझे नहीं लगता कि सही कार्रवाई उतनी ही स्पष्ट है जितना आप इसे करना चाहते हैं।

— पीजो

5

आपके पास 2 घोड़े हैं। उन्हें रेस दें।

— मस्त

@ पीजो मैं नहीं। कुछ विचार हमेशा इन चीजों में जाना चाहिए। मेरे मामले में, यह UI कोड में छोरों के लिए था। एक यूआई उदाहरण, कुछ छोरों, कुछ पुनरावृत्तियों। रिकॉर्ड के लिए, मैंने आपकी टिप्पणी को गलत ठहराया। :)

— अल्मो

44

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

जरुरी नहीं। एप्लीकेशन सॉफ्टवेयर की तरह ही, एक गेम में कोड होता है, जो प्रदर्शन-महत्वपूर्ण और कोड होता है, जो नहीं होता है।

यदि कोड को प्रति फ्रेम कई हजार बार निष्पादित किया जाता है, तो इस तरह के निम्न-स्तर का अनुकूलन समझ में आता है। (यद्यपि आप पहले यह देखना चाहते हैं कि क्या वास्तव में इसे कॉल करना आवश्यक है, अक्सर। सबसे तेज़ कोड वह कोड है जो आप नहीं चलाते हैं)

यदि कोड को हर दो सेकंड में एक बार निष्पादित किया जाता है, तो प्रदर्शन की तुलना में पठनीयता और स्थिरता अधिक महत्वपूर्ण है।

मैंने पढ़ा है कि एकता 3 डी गुणों के माध्यम से इनलाइन एक्सेस के लिए निश्चित नहीं है, इसलिए संपत्ति का उपयोग करने से एक अतिरिक्त फ़ंक्शन कॉल होगा।

आप की शैली में तुच्छ गुणों के साथ int Foo { get; private set; }बहुत कुछ निश्चित हो सकता है कि कंपाइलर संपत्ति के आवरण को दूर का अनुकूलन करेगा। परंतु:

यदि आपके पास वास्तव में कार्यान्वयन है, तो आप अब और निश्चित नहीं हो सकते। कार्यान्वयन जितना अधिक जटिल होगा, कम संभावना है कि कंपाइलर इसे इनलाइन करने में सक्षम होगा।
गुण जटिलता को छिपा सकते हैं। यह दोधारी तलवार है। एक ओर, यह आपके कोड को अधिक पठनीय और परिवर्तनशील बनाता है। लेकिन दूसरी तरफ, एक अन्य डेवलपर जो आपकी कक्षा की एक संपत्ति का उपयोग करता है, वह सोच सकता है कि वे सिर्फ एक ही चर पर पहुंच रहे हैं और यह महसूस नहीं कर रहे हैं कि आपने वास्तव में उस संपत्ति के पीछे कितना कोड छिपाया है। जब कोई संपत्ति कम्प्यूटेशनल रूप से महंगी होने लगती है, तो मैं इसे स्पष्ट GetFoo()/ SetFoo(value)विधि में रिफ्लेक्टर करता हूं : इसका मतलब है कि पर्दे के पीछे बहुत कुछ हो रहा है। (या अगर मुझे यह सुनिश्चित करने की आवश्यकता है कि दूसरों को संकेत मिले: CalculateFoo()/ SwitchFoo(value))

— फिलिप
स्रोत

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

— सुपरकैट

5

"तो मैं इसे एक स्पष्ट GetFoo () / SetFoo (मूल्य) विधि में फिर से सम्मिलित करता हूं:" - अच्छी बात है, मैं गुणों में से भारी संचालन को तरीकों में स्थानांतरित करता हूं।

— मार्क रोजर्स

क्या यह पुष्टि करने का एक तरीका है कि यूनिटी 3 डी कंपाइलर आपके द्वारा उल्लिखित अनुकूलन (IL2CPP में और मोनो एंड्रॉयड के लिए बनाता है) बनाता है?

— पीजो

9

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

— लुआं

9

जब संदेह हो, तो सर्वोत्तम प्रथाओं का उपयोग करें।

आप संदेह में हैं।

यह आसान जवाब था। वास्तविकता निश्चित रूप से अधिक जटिल है।

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

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

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

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

— पीटर - अनबन रॉबर्ट हार्वे
स्रोत

2

यह .net रनटाइम इनलाइन सरल गुणों के लिए बहुत आसान है, और अक्सर यह करता है। लेकिन, यह इनलाइनिंग आम तौर पर प्रोफाइलरों द्वारा अक्षम की जाती है, इसलिए इसे गुमराह करना आसान है और सोचते हैं कि सार्वजनिक संपत्ति को सार्वजनिक क्षेत्र में बदलने से सॉफ्टवेयर में तेजी आएगी।

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

एक पेशेवर C # प्रोग्रामर के रूप में मैंने अपने 10 वर्षों में प्रॉपर्टी का उपयोग करने का मुख्य कारण अन्य प्रोग्रामर को यह बताना था कि मैं कोडिंग मानक के अनुरूप नहीं था। यह एक अच्छा व्यापार था, क्योंकि शायद ही कभी एक संपत्ति का उपयोग न करने का एक अच्छा कारण था।

— इयान रिंगरोज
स्रोत

2

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

उसके कारण, आपको अक्सर वेक्टर और मैट्रिक्स प्रकार वाले बेहतर प्रदर्शन मिलेंगे जिनमें गुण नहीं हैं लेकिन नग्न क्षेत्र हैं।

टीके में सर्वोत्तम प्रथाएं नहीं बन रही हैं। कुछ कार्गो पंथ के बावजूद, सामान्य तौर पर एक अच्छे कारण के लिए सर्वोत्तम प्रथाएं हैं।

इस मामले में, हमारे पास एक जोड़ी है:

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

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

हाँ, वहाँ मूल्य है जो इंट उद्योग किया जा रहा है देख रहा है। हालांकि, क्या आपके पास सर्वोत्तम प्रथाओं के खिलाफ जाने की प्रेरणा है? या आप सिर्फ सर्वोत्तम प्रथाओं के खिलाफ जा रहे हैं - कोड को तर्क के लिए कठिन बना रहे हैं - सिर्फ इसलिए कि किसी और ने किया था? आह, वैसे, "अन्य लोग करते हैं" यह है कि आप एक कार्गो पंथ कैसे शुरू करते हैं।

तो ... क्या आपका खेल धीमा चल रहा है? आप अड़चन को दूर करने और इसे ठीक करने के बजाय यह तय करने के बजाय कि यह क्या हो सकता है। आप निश्चिंत हो सकते हैं कि कंपाइलर बहुत सारे ऑप्टिमाइज़ेशन करेगा, इस वजह से, संभावना है कि आप गलत समस्या देख रहे हैं।

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

अंत में, क्या आप सर्वोत्तम प्रथाओं के खिलाफ जाकर कुछ कमाते हैं?

आप के मामले के लिए (एकता और एंड्रॉयड के लिए मोनो), क्या एकता संदर्भ द्वारा मान लेती है? यदि ऐसा नहीं होता है, तो यह वैसे भी मूल्यों की नकल करेगा, कोई प्रदर्शन लाभ नहीं होगा।

यदि ऐसा होता है, यदि आप इस डेटा को एक एपीआई में ले जा रहे हैं जो रेफ लेती है। क्या यह क्षेत्र को सार्वजनिक करने के लिए समझ में आता है, या आप सीधे एपीआई को कॉल करने में सक्षम प्रकार बना सकते हैं?

हां, निश्चित रूप से, ऐसे अनुकूलन हो सकते हैं जो आप नग्न क्षेत्रों के साथ संरचनाओं का उपयोग करके कर सकते हैं। उदाहरण के लिए, आप उन्हें ~~पॉइंटर्स के~~ साथ एक्सेस करते हैं Span<T> या इसी तरह । वे मेमोरी पर भी कॉम्पैक्ट होते हैं, जिससे उन्हें नेटवर्क पर भेजने या स्थायी भंडारण में डालने में आसानी होती है (और हां वे प्रतियां हैं)।

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

— Theraot
स्रोत

1

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

:

मुझे पता है कि समय से पहले अनुकूलन खराब है, लेकिन जैसा कि मैंने कहा, खेल के विकास में आप कुछ धीमी गति से नहीं बनाते हैं जब एक समान प्रयास इसे तेज कर सकता है।

आप जानते हैं कि समय से पहले अनुकूलन खराब है, लेकिन यह केवल आधी कहानी है (नीचे पूरा उद्धरण देखें)। यहां तक कि खेल के विकास में भी, सब कुछ जितना संभव हो उतना तेज़ होने की आवश्यकता नहीं है।

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

" वास्तविक समस्या यह है कि प्रोग्रामर ने गलत स्थानों पर और गलत समय पर दक्षता के बारे में चिंता करने में बहुत अधिक समय बिताया है । समयपूर्व अनुकूलन प्रोग्रामिंग में सभी बुराई (या कम से कम अधिकांश) की जड़ है।" डोनाल्ड नुथ, 1974।

— विंसेंट ओ'सुलीवन
स्रोत

1

उस तरह के बुनियादी सामान के लिए, सी # ऑप्टिमाइज़र इसे वैसे भी ठीक करने जा रहा है। यदि आप इसके बारे में चिंता करते हैं (और यदि आप इसके बारे में 1% से अधिक कोड के लिए चिंता करते हैं , तो आप इसे गलत कर रहे हैं ) आपके लिए एक विशेषता बनाई गई थी। विशेषता [MethodImpl(MethodImplOptions.AggressiveInlining)]बहुत अधिक संभावना को बढ़ाती है एक विधि अंतर्निर्मित होगी (संपत्ति गेटर्स और बसने के तरीके हैं)।

— यहोशू
स्रोत

0

खेतों की बजाय गुणों के रूप में संरचना-प्रकार के सदस्यों को उजागर करने से अक्सर खराब प्रदर्शन और शब्दार्थ मिलेगा, विशेष रूप से ऐसे मामलों में जहां संरचनाओं को वास्तव में "quirky ऑब्जेक्ट्स" के बजाय संरचनाओं के रूप में माना जाता है।

.NET में एक संरचना एक साथ डक्ट-टैप किए गए फ़ील्ड का एक संग्रह है, और जो कुछ उद्देश्यों के लिए एक इकाई के रूप में माना जा सकता है। .NET फ्रेमवर्क को क्लास ऑब्जेक्ट्स के समान संरचनाओं का उपयोग करने की अनुमति देने के लिए डिज़ाइन किया गया है, और कई बार यह सुविधाजनक हो सकता है।

आसपास के ढांचे की अधिकांश सलाह इस धारणा पर आधारित है कि प्रोग्रामर संरचनाओं को ऑब्जेक्ट के रूप में उपयोग करना चाहते हैं, न कि खेतों के टेप-संग्रह के रूप में। दूसरी ओर, ऐसे कई मामले हैं जहां कुछ ऐसा करना उपयोगी हो सकता है जो खेतों के एक टेप-एक गुच्छा के रूप में व्यवहार करता है। अगर यह है कि एक की जरूरत है, .NET सलाह प्रोग्रामर और कंपाइलर के लिए एक जैसे अनावश्यक काम को जोड़ देगा, केवल सीधे संरचनाओं का उपयोग करने की तुलना में बदतर प्रदर्शन और शब्दार्थ।

संरचनाओं का उपयोग करते समय ध्यान में रखने के लिए सबसे बड़े सिद्धांत हैं:

मूल्य द्वारा संरचनाओं को पास या वापस न करें या अन्यथा उन्हें अनावश्यक रूप से कॉपी किया जाए।
यदि सिद्धांत # 1 का पालन किया जाता है, तो बड़ी संरचनाएं छोटे लोगों के साथ भी प्रदर्शन करेंगी।

यदि Alphablobएक संरचना है जिसमें 26 सार्वजनिक intफ़ील्ड शामिल हैं, जिसका नाम az है, और एक प्रॉपर्टी गेट्टर है, abजो अपने aऔर bफ़ील्ड्स का योग लौटाता है , तो दिए गए Alphablob[] arr; List<Alphablob> list;कोड int foo = arr[0].ab + list[0].ab;को फ़ील्ड्स aऔर रीडिंग bकी arr[0]आवश्यकता होगी, लेकिन list[0]फिर भी सभी 26 फ़ील्ड्स को पढ़ने की आवश्यकता होगी सभी को अनदेखा करें लेकिन उनमें से दो। यदि कोई एक सामान्य सूची-जैसा संग्रह करना चाहता था alphaBlob, जो किसी संरचना के साथ कुशलता से काम कर सके , तो किसी को अनुक्रमणिका को एक विधि से बदलना चाहिए:

delegate ActByRef<T1,T2>(ref T1 p1, ref T2 p2);
actOnItem<TParam>(int index, ActByRef<T, TParam> proc, ref TParam param);

जो तब आह्वान करेगा proc(ref backingArray[index], ref param);। इस तरह के संग्रह को देखते हुए, अगर कोई इसके sum = myCollection[0].ab;साथ बदलता है

int result;
myCollection.actOnItem<int>(0, 
  ref (ref alphaBlob item, ref int dest)=>dest = item,
  ref result);

कि alphaBlobसंपत्ति पाने वाले में इस्तेमाल नहीं होने जा रहे हैं के कुछ हिस्सों को कॉपी करने की आवश्यकता से बचना होगा । चूंकि पारित प्रतिनिधि अपने refमापदंडों के अलावा किसी अन्य चीज का उपयोग नहीं करता है , इसलिए संकलक एक स्थिर प्रतिनिधि को पारित कर सकता है।

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

— supercat
स्रोत

नमस्ते, क्या आपने गलत पृष्ठ पर अपना उत्तर पोस्ट किया है?

— पीजो

@pojo: शायद मुझे यह स्पष्ट कर देना चाहिए कि उत्तर का उद्देश्य ऐसी स्थिति की पहचान करना है जहां खेतों के बजाय गुणों का उपयोग करना बुरा है, और यह पहचानना कि खेतों का प्रदर्शन और अर्थ लाभ कैसे प्राप्त किया जा सकता है, जबकि अभी भी पहुंच में कमी है।

— सुपरकैट

@piojo: क्या मेरा संपादन चीजों को स्पष्ट करता है?

— सुपरकैट

"सूची के सभी 26 क्षेत्रों को पढ़ने की आवश्यकता होगी [0] भले ही यह सभी को अनदेखा करेगा लेकिन उनमें से दो।" क्या? क्या आपको यकीन है? क्या आपने MSIL की जाँच की है? C # लगभग हमेशा संदर्भ के द्वारा वर्ग प्रकार पास करता है।

— pjc50

@ pjc50: किसी संपत्ति को पढ़ने से मूल्य के अनुसार परिणाम मिलता है। यदि दोनों के लिए अनुक्रमित पानेवाला listऔर संपत्ति पाने वाला abदोनों में लाइन में हैं, तो यह संभव हो सकता है कि JITTER के लिए यह पहचानना कि केवल सदस्य हैं aऔर bजरूरत है, लेकिन मैं वास्तव में इस तरह के काम करने वाले किसी भी JITTER संस्करण से अनजान हूं।

— सुपरकैट