परावर्तन में तेजी लाने के बारे में असफल लेख

मैं तुरंत लेख का शीर्षक समझाऊंगा। मूल योजना एक सरल लेकिन यथार्थवादी उदाहरण का उपयोग करके प्रतिबिंब के उपयोग को तेज करने के बारे में अच्छी, विश्वसनीय सलाह देना था, लेकिन बेंचमार्किंग के दौरान यह पता चला कि प्रतिबिंब उतना धीमा नहीं है जितना मैंने सोचा था, LINQ मेरे बुरे सपने की तुलना में धीमा है। लेकिन अंत में यह पता चला कि मैंने भी माप में गलती की है... इस जीवन कहानी का विवरण कट के नीचे और टिप्पणियों में है। चूंकि उदाहरण काफी सामान्य है और सिद्धांत रूप में लागू किया गया है जैसा कि आमतौर पर किसी उद्यम में किया जाता है, यह काफी दिलचस्प साबित हुआ, जैसा कि मुझे लगता है, जीवन का प्रदर्शन: लेख के मुख्य विषय की गति पर प्रभाव था बाहरी तर्क के कारण ध्यान देने योग्य नहीं: Moq, Autofac, EF Core और अन्य "बैंडिंग"।

मैंने इस लेख से प्रभावित होकर काम करना शुरू किया: परावर्तन धीमा क्यों है?

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

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

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

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

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

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

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

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

यह कैसे हासिल किया जाता है? अनिवार्य रूप से, यह उस तर्क से अलग नहीं है जिसका उपयोग प्लेटफ़ॉर्म स्वयं JIT कोड उत्पन्न करने के लिए करता है। जब किसी विधि को पहली बार कॉल किया जाता है, तो इसे संकलित किया जाता है (और, हाँ, यह प्रक्रिया तेज़ नहीं है); बाद की कॉल पर, नियंत्रण पहले से संकलित विधि में स्थानांतरित कर दिया जाता है, और कोई महत्वपूर्ण प्रदर्शन गिरावट नहीं होगी।

हमारे मामले में, आप JIT संकलन का भी उपयोग कर सकते हैं और फिर उसके AOT समकक्षों के समान प्रदर्शन के साथ संकलित व्यवहार का उपयोग कर सकते हैं। इस मामले में अभिव्यक्ति हमारी सहायता के लिए आएगी।

विचाराधीन सिद्धांत को संक्षेप में इस प्रकार तैयार किया जा सकता है:
आपको संकलित फ़ंक्शन वाले प्रतिनिधि के रूप में प्रतिबिंब के अंतिम परिणाम को कैश करना चाहिए। यह आपके प्रकार, कार्यकर्ता के क्षेत्रों में प्रकार की जानकारी के साथ सभी आवश्यक वस्तुओं को कैश करने के लिए भी समझ में आता है, जो वस्तुओं के बाहर संग्रहीत होते हैं।

इसमें तर्क है. सामान्य ज्ञान हमें बताता है कि यदि किसी चीज़ को संकलित और कैश किया जा सकता है, तो उसे किया जाना चाहिए।

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

अब कोड के बारे में. आइए एक उदाहरण देखें जो मेरे हालिया दर्द पर आधारित है जिसका मुझे एक गंभीर क्रेडिट संस्थान के गंभीर उत्पादन में सामना करना पड़ा। सभी संस्थाएं काल्पनिक हैं ताकि कोई अनुमान न लगा सके।

कुछ तो सार है. संपर्क होने दो. एक मानकीकृत बॉडी वाले अक्षर होते हैं, जिनसे पार्सर और हाइड्रेटर समान संपर्क बनाते हैं। एक पत्र आया, हमने इसे पढ़ा, इसे कुंजी-मूल्य जोड़े में पार्स किया, एक संपर्क बनाया, और इसे डेटाबेस में सहेजा।

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

हम लागू करते हैं, परीक्षण बनाते हैं। काम करता है.

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

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

"तेज़" (बेंचमार्क में उपसर्ग तेज़):

 protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var setterMapItem in _proprtySettersMap)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == setterMapItem.Key);
                setterMapItem.Value(contact, correlation?.Value);
            }
            return contact;
        }

जैसा कि हम देख सकते हैं, सेटर गुणों के साथ एक स्थिर संग्रह का उपयोग किया जाता है - संकलित लैम्बडा जो सेटर इकाई को कॉल करता है। निम्नलिखित कोड द्वारा बनाया गया:

        static FastContactHydrator()
        {
            var type = typeof(Contact);
            foreach (var property in type.GetProperties())
            {
                _proprtySettersMap[property.Name] = GetSetterAction(property);
            }
        }

        private static Action<Contact, string> GetSetterAction(PropertyInfo property)
        {
            var setterInfo = property.GetSetMethod();
            var paramValueOriginal = Expression.Parameter(property.PropertyType, "value");
            var paramEntity = Expression.Parameter(typeof(Contact), "entity");
            var setterExp = Expression.Call(paramEntity, setterInfo, paramValueOriginal).Reduce();
            
            var lambda = (Expression<Action<Contact, string>>)Expression.Lambda(setterExp, paramEntity, paramValueOriginal);

            return lambda.Compile();
        }

सामान्य तौर पर यह स्पष्ट है. हम संपत्तियों का पता लगाते हैं, उनके लिए प्रतिनिधि बनाते हैं जो सेटर्स को कॉल करते हैं, और उन्हें सहेजते हैं। फिर जरूरत पड़ने पर हम फोन करते हैं.

"धीमा" (बेंचमार्क में उपसर्ग धीमा):

        protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var property in _properties)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == property.Name);
                if (correlation?.Value == null)
                    continue;

                property.SetValue(contact, correlation.Value);
            }
            return contact;
        }

यहां हम तुरंत संपत्तियों को बायपास करते हैं और सीधे SetValue को कॉल करते हैं।

स्पष्टता के लिए और एक संदर्भ के रूप में, मैंने एक सरल विधि लागू की जो उनके सहसंबंध जोड़े के मूल्यों को सीधे इकाई क्षेत्रों में लिखती है। उपसर्ग - मैनुअल.

अब आइए बेंचमार्कडॉटनेट लें और प्रदर्शन की जांच करें। और अचानक... (स्पॉइलर - यह सही परिणाम नहीं है, विवरण नीचे हैं)

हम यहाँ क्या देखते हैं? वे विधियाँ जो विजयी रूप से तेज़ उपसर्ग को सहन करती हैं, वे धीमी उपसर्ग वाली विधियों की तुलना में लगभग सभी पासों में धीमी हो जाती हैं। यह काम के आवंटन और गति दोनों के लिए सच है। दूसरी ओर, जहां भी संभव हो, LINQ विधियों का उपयोग करके मैपिंग का एक सुंदर और सुरुचिपूर्ण कार्यान्वयन, इसके विपरीत, उत्पादकता को काफी कम कर देता है। अंतर क्रम का है. पासों की अलग-अलग संख्या से प्रवृत्ति नहीं बदलती। फर्क सिर्फ पैमाने का है. LINQ के साथ यह 4-200 गुना धीमा है, लगभग उसी पैमाने पर अधिक कचरा है।

नवीनीकृत

मुझे अपनी आंखों पर विश्वास नहीं हुआ, लेकिन इससे भी महत्वपूर्ण बात यह है कि हमारे सहकर्मी को मेरी आंखों या मेरे कोड पर विश्वास नहीं हुआ - दिमित्री तिखोनोव 0x1000000. मेरे समाधान की दोबारा जांच करने के बाद, उन्होंने शानदार ढंग से एक त्रुटि की खोज की और बताया कि कार्यान्वयन में प्रारंभिक से अंतिम तक कई बदलावों के कारण मैं चूक गया। Moq सेटअप में पाए गए बग को ठीक करने के बाद, सभी परिणाम सही हो गए। पुनः परीक्षण परिणामों के अनुसार, मुख्य प्रवृत्ति नहीं बदलती - LINQ अभी भी प्रतिबिंब से अधिक प्रदर्शन को प्रभावित करता है। हालाँकि, यह अच्छा है कि अभिव्यक्ति संकलन के साथ काम व्यर्थ नहीं किया गया है, और परिणाम आवंटन और निष्पादन समय दोनों में दिखाई देता है। पहला प्रक्षेपण, जब स्थैतिक क्षेत्रों को आरंभ किया जाता है, "तेज" विधि के लिए स्वाभाविक रूप से धीमा होता है, लेकिन फिर स्थिति बदल जाती है।

यहाँ पुनः परीक्षण का परिणाम है:

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

बेंचमार्क कोड यहां उपलब्ध है. कोई भी मेरे शब्दों की दोबारा जांच कर सकता है:
हाब्रारिफ्लेक्शन टेस्ट

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

पीपीएस: उपयोगकर्ता को धन्यवाद दिमित्री तिखोनोव @0x1000000 Moq की स्थापना में मेरी त्रुटि का पता लगाने के लिए, जिसने पहले माप को प्रभावित किया। यदि किसी पाठक के पास पर्याप्त कर्म हैं तो कृपया इसे लाइक करें। वह आदमी रुका, उस आदमी ने पढ़ा, उस आदमी ने दोबारा जाँच की और गलती बताई। मुझे लगता है कि यह सम्मान और सहानुभूति के योग्य है।

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

स्रोत: www.habr.com