लूप

Question

की अवधि के लिए स्थैतिक बने गुणों का कंपाइलर ऑप्टिमाइज़ेशन मैं Improving .NET Application Performance and Scalability पढ़ रहा था।

यदि आप डेटा कि पाश की अवधि के लिए स्थिर है का उपयोग करें, यह बजाय बार-बार एक क्षेत्र या संपत्ति तक पहुँचने का पाश से पहले प्राप्त: शीर्षक बचें दोहराए फील्ड या संपत्ति पहुँच खंड एक दिशानिर्देश शामिल हैं।

निम्नलिखित कोड इस का एक उदाहरण के रूप में दिया जाता है:

for (int item = 0; item < Customer.Orders.Count; item++) 
{ 
    CalculateTax(Customer.State, Customer.Zip, Customer.Orders[item]); 
} 

string state = Customer.State; 
string zip = Customer.Zip; 
int count = Customers.Orders.Count; 
for (int item = 0; item < count; item++) 
{ 
    CalculateTax(state, zip, Customer.Orders[item]); 
} 

लेख राज्यों हो जाता है:

ध्यान दें कि यदि इन क्षेत्रों हैं, यह संकलक के लिए के लिए यह अनुकूलन automatica संभव हो सकता है lly। यदि वे गुण हैं, तो यह कम संभावना है। यदि गुण वर्चुअल हैं, तो यह स्वचालित रूप से नहीं किया जा सकता है।

इस तरह से संकलक द्वारा गुणों को अनुकूलित करने के लिए "बहुत कम संभावना" क्यों है, और जब किसी एक विशेष संपत्ति के लिए उम्मीद की जा सकती है या अनुकूलित नहीं किया जा सकता है? मैं मानता हूं कि उन गुणों जहां एक्सेसर्स में अतिरिक्त ऑपरेशन किए जाते हैं, संकलक को अनुकूलित करने के लिए कठिन होते हैं, और जो कि केवल बैकिंग फ़ील्ड को संशोधित करते हैं, उन्हें अनुकूलित करने की अधिक संभावना होती है, लेकिन कुछ और ठोस नियम पसंद करेंगे। क्या स्वत: कार्यान्वित गुण हमेशा अनुकूलित होते हैं?

Answer 1

यह दो अनुकूलन लागू करने के लिए घबराना की आवश्यकता है:

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

ध्यान दें कि ग्राहक-ऑर्डर [] इंडेक्सर ग्राहक को बदल देगा, तो हाथ-अनुकूलित कोड गलत होगा। स्टेटस संपत्ति। इस तरह आलसी कोड बिल्कुल निश्चित रूप से असंभव है लेकिन ऐसा नहीं है कि यह कभी नहीं किया गया है :) अनुकूलक को सुनिश्चित करना होगा।

दूसरा, फ़ील्ड एक्सेस कोड को लूप बॉडी से बाहर निकाला जाना है। "Invariant कोड गति" नामक एक अनुकूलन। सरल संपत्ति गेटर कोड पर काम करता है जब जिटर साबित कर सकता है कि लूप बॉडी के अंदर बयान मूल्य को प्रभावित नहीं करते हैं।

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

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

जिटर अनुकूलन is here पर एक पृष्ठभूमिकर्ता।

Answer 2

इस तरह से संकलक द्वारा गुणों को अनुकूलित करने के लिए "बहुत कम संभावना" क्यों है, और जब किसी एक विशेष संपत्ति के लिए उम्मीद की जा सकती है या अनुकूलित नहीं किया जा सकता है?

गुण हमेशा एक फ़ील्ड के लिए रैपर नहीं होते हैं। यदि किसी संपत्ति में तर्क की कोई डिग्री है, तो यह संकलक साबित करने के लिए काफी कठिन हो जाता है कि लूप शुरू होने पर पहले मूल्य को फिर से उपयोग करना सही है।

एक चरम उदाहरण के रूप में, पर विचार

private Random rnd = new Random(); 
public int MyProperty 
{ 
    get { return rnd.Next(); } 
}