सीएलआर में अनुकूलन और जेनरिक

इस लेख में, जॉन स्कीट का वर्णन करेगा कि कैसे सबसे सरल भाषा का निर्माण आपके कार्यक्रम को धीमा कर देता है और उन्हें कैसे त्वरित किया जा सकता है।

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

प्रतिबंध नया ()

मान लीजिए, उदाहरण के लिए, हमारे पास SteppedPattern टाइप है (लेखक अपने पुस्तकालय के उदाहरण के साथ अनुकूलन पर चर्चा करता है, Noda Time , लगभग। अनुवाद।), जिसमें जेनेरिक टाइप TBucket । मैं केवल ध्यान देता हूं कि यह महत्वपूर्ण है कि इससे पहले कि मैं मूल्य को TBucket , मैं TBucket क्लास की एक नई वस्तु बनाना चाहता हूं। विचार यह है कि जानकारी के बिट्स को एक Bucket में ढेर किया जाता है जहां वे पार्स होते हैं। और ऑपरेशन पूरा होने के बाद, वे ParseResult तक ParseResult । तो हर लाइन पार्सिंग ऑपरेशन के लिए TBucket की एक उदाहरण की आवश्यकता होती है। हम उन्हें जेनेरिक प्रकारों के मामले में कैसे बना सकते हैं?

हम बिना पैरामीटर के टाइप कंस्ट्रक्टर को कॉल करके ऐसा कर सकते हैं। मैं यह नहीं सोचना चाहता कि क्या पास किए गए प्रकारों में इस तरह का एक निर्माणकर्ता है, इसलिए मैं सिर्फ एक new() बाधा new TBucket() और new TBucket() कॉल करता new TBucket() ।

 // Somewhat simplified... internal sealed class SteppedPattern<TResult, TBucket> : IParsePattern<TResult>    where TBucket : new() {    public ParseResult<TResult> Parse(string value)   {       TBucket bucket = new TBucket();        // Rest of parsing goes here   } } 

वाह! काफी सरल। हालांकि, दुर्भाग्य से, मैंने इस तथ्य को खो दिया कि कोड की यह एकल पंक्ति उस समय का 75% भाग लेगी जहां हमें लाइन को पार्स करने में समय लगता है। और यह सिर्फ एक खाली Bucket का निर्माण है - सबसे सरल वर्ग जो सरलतम रेखा को पार करता है! जब मैंने इसे समझा तो इसने मुझे झकझोर दिया।

हम प्रदाता का उपयोग करके ठीक करते हैं

हमारा फिक्स बहुत सरल होगा। हमें केवल अपने प्रकार को बताने की आवश्यकता है कि वस्तु को कैसे त्वरित किया जाए। हम एक प्रतिनिधि की मदद से ऐसा करते हैं:

 // Somewhat simplified... internal sealed class SteppedPattern<TResult, TBucket> : IParsePattern<TResult> {    private readonly Func<TBucket> bucketProvider;    internal SteppedPattern(Func<TBucket> bucketProvider)   {        this.bucketProvider = bucketProvider;   }    public ParseResult<TResult> Parse(string value)   {       TBucket bucket = bucketProvider();        // Rest of parsing goes here   } } 

अब मैं new StoppedPattern(() => new OffsetBucket()) , या ऐसा कुछ कह सकता हूं। इसका मतलब यह भी है कि मैं कॉस्ट्रक्टर को आंतरिक के रूप में छोड़ सकता हूं और फिर कभी इसका ध्यान नहीं रखूंगा। और, बाद के कोड के लेखन को और सरल बनाने के लिए, मैं बाद की पंक्तियों को पार्स करने के लिए पुराने बकेट का उपयोग भी कर सकता था।

मुझे गोलियाँ चाहिए!

यह मुझे लगता है कि हर कोई अपने दम पर परीक्षण नहीं चलाना चाहता है, लेकिन अधिक समाप्त परिणामों को देखना चाहता है। इसलिए, मैंने बेंचमार्क के परिणाम देने का फैसला किया, जो मैंने जेनेरिक प्रकार बनाने के केवल समय की जांच करने के लिए किया था। यह दिखाने के लिए कि ये परिणाम कितने महत्वहीन होंगे, मैं यह इंगित करूँगा कि तालिका में दर्ज मूल्य मिलीसेकंड में मापा गया है। और इस समय के दौरान, 100 मिलियन ऑपरेशन किए गए, जिन्हें हम परीक्षण करेंगे। इसलिए, जब तक आपका कोड जेनेरिक प्रकार बनाने के संचालन को बार-बार लागू करने पर आधारित नहीं है, तब तक आपको कोड को फिर से लिखना नहीं चाहिए। हालांकि, इसे भविष्य के लिए याद रखें।

एक तरह से या किसी अन्य, हमारे कोड को चार प्रकारों के साथ काम करने के लिए डिज़ाइन किया गया है: दो कक्षाएं और दो संरचनाएं। और उनमें से प्रत्येक के लिए - एक छोटे और बड़े संस्करण के साथ (मतलब, जाहिरा तौर पर, GAC लिए छोटे और बड़े संस्करण, 85K से छोटे और बड़े), 32-बिट और 64-बिट मशीनों पर, CLR v2 , v4 के लिए। मेरी 64-बिट मशीन अपने आप में तेज़ है, इसलिए आपको उसी मशीन के अंदर परिणामों की तुलना करने की आवश्यकता है।

सीएलआर v4: 32-बिट परिणाम (एमएस प्रति 100 मिलियन पुनरावृत्तियों)


सीएलआर v4: 64-बिट परिणाम (एमएस प्रति 100 मिलियन पुनरावृत्तियों)


सीएलआर वी 2: 32-बिट परिणाम (प्रति 100 मिलियन पुनरावृत्ति एमएस)


सीएलआर वी 2: 64-बिट परिणाम (प्रति 100 मिलियन पुनरावृत्ति एमएस)


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

और, ज़ाहिर है, आप बेंचमार्क को डाउनलोड करके देख सकते हैं कि यह आपके मशीन पर कैसे काम करता है।

"हुड के नीचे" क्या हो रहा है?

जहां तक ​​मैं समझता हूं, new() अवरोध का समर्थन करने के लिए कोई IL निर्देश नहीं है। इसके बजाय, कंपाइलर Activator.CreateInstance [T] मंगलाचरण निर्देश सम्मिलित करता है। जाहिर है, यह किसी भी मामले में है कि प्रतिनिधि को बुलाए जाने की तुलना में धीमा है, जैसा कि इस मामले में, हम प्रतिबिंब के माध्यम से हमारे लिए एक उपयुक्त निर्माता खोजने की कोशिश करते हैं और इसे कॉल करते हैं। मुझे वास्तव में आश्चर्य हुआ कि यह अनुकूलित नहीं था। आखिरकार, स्पष्ट समाधान भविष्य के उपयोग के लिए प्रतिनिधियों और कैशिंग का उपयोग करना है। मैं उनके द्वारा किए गए मुद्दों पर बहस नहीं बढ़ाऊंगा, क्योंकि अंत में, उनका समाधान अतिरिक्त मेमोरी का उपभोग नहीं करता है जो कैश पर कब्जा कर लेगा।

मुझे और बेंचमार्क चाहिए !!

(लेख के दूसरे भाग से लिया गया)

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

• मैं लैम्ब्डा के भावों का उपयोग करता हूं: एक्शन फू = () => ();
  

    private static void Lambda<T>() { Action foo = () => {}; if (foo == null) { throw new Exception(); } } 

  
  
• कंपाइलर मेरे लिए क्या करना चाहेगा: एक अलग कैश जो डेलिगेट को क्लास की एक आवृत्ति बनाने के लिए स्टोर करता है।
  
  

    private static void FakeCachedLambda<T>() { if (FakeLambdaCache<T>.CachedAction == null) { FakeLambdaCache<T>.CachedAction = FakeLambdaCache<T>.NoOp; } Action foo = FakeLambdaCache<T>.CachedAction; if (foo == null) { throw new Exception(); } } private static class FakeLambdaCache<T> { internal static Action CachedAction; internal static void NoOp() {} } 

  
  
• संकलक वास्तव में एक लंबोदर अभिव्यक्ति के साथ क्या करता है: हम एक अलग जेनेरिक विधि लिखेंगे और हम method group conversion
  

    private static void GenericMethodGroup<T>() { Action foo = NoOp<T>; if (foo == null) { throw new Exception(); } } 

  
  
• कंपाइलर क्या कर सकता है: बाद में method group conversion लागू करने के लिए एक अलग गैर- generic विधि का उपयोग करें
  
  

    private static void NonGenericMethodGroup<T>() { Action foo = NoOp; if (foo == null) { throw new Exception(); } } 

  
  
• स्थैतिक गैर- generic जेनेरिक प्रकार विधि में method group conversion का उपयोग करना;
  

    private static void StaticMethodOnGenericType<T>() { Action foo = SampleGenericClass<T>.NoOpStatic; if (foo == null) { throw new Exception(); } } 

  
  
• गैर-स्थिर गैर-जेनेरिक जेनेरिक पद्धति में method group conversion का उपयोग करना, जेनेरिक कैश का उपयोग करके जेनेरिक वर्ग की आवृत्ति की ओर इशारा करते हुए एकल फ़ील्ड के साथ।
  हां, बाद वाला थोड़ा जटिल दिखता है, लेकिन यह बहुत आसान लगता है:
  

    private static void InstanceMethodOnGenericType<T>() { Action foo = ClassHolder<T>.SampleInstance.NoOpInstance; if (foo == null) { throw new Exception(); } } 

मैं सभी अनसुलझी परिभाषाओं को भी प्रकट करूंगा:

  private static void NoOp() {} private static void NoOp<T>() {} private class ClassHolder<T> { internal static SampleGenericClass<T> SampleInstance = new SampleGenericClass<T>(); } private class SampleGenericClass<T> { internal static void NoOpStatic() { } internal void NoOpInstance() { } } 

ध्यान दें कि हम यह सब सामान्य तरीके से करते हैं, और इसे प्रत्येक प्रकार के लिए कहते हैं: Int32 और String । और, क्या ध्यान रखना महत्वपूर्ण है, हम किसी भी चर पर कब्जा नहीं करते हैं, और सामान्य पैरामीटर विधि निकाय के कार्यान्वयन के किसी भी भाग में शामिल नहीं है।

परीक्षण के परिणाम

फिर से, परिणाम 10 मिलियन ऑपरेशन में मिलीसेकंड में प्रस्तुत किए जाते हैं। मैं उन्हें 100 मिलियन ऑपरेशन पर लॉन्च नहीं करना चाहता, क्योंकि यह बहुत धीमा होगा। मैं यह भी स्पष्ट करूंगा कि परीक्षण x64 JIT पर किया गया था


हां, एक जेनेरिक पैरामीटर के रूप में एक जेनेरिक पैरामीटर के रूप में एक प्रतिनिधि बनाना एक जेनेरिक पैरामीटर के रूप में मूल्य प्रकार के लिए की तुलना में 150 गुना धीमा है। और ऐसा लगता है कि मैं इसके बारे में जानने वाला पहला व्यक्ति हूं। बेशक, यह CLR टीम ब्लॉग पर जवाब सुनने के लिए बहुत दिलचस्प होगा ...

निष्कर्ष

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

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