🥇 द्रुत प्रतिबिम्ब बारे असफल लेख

म तुरुन्तै लेखको शीर्षक व्याख्या गर्नेछु। मूल योजना सरल तर यथार्थपरक उदाहरण प्रयोग गरेर प्रतिबिम्बको प्रयोगलाई कसरी गति दिने भन्ने बारे राम्रो, भरपर्दो सल्लाह दिनु थियो, तर बेन्चमार्किङको क्रममा यो पत्ता लाग्यो कि प्रतिबिम्ब मैले सोचेको जस्तो ढिलो छैन, LINQ मेरा दुःस्वप्नहरूमा भन्दा ढिलो छ। तर अन्तमा थाहा भयो कि मैले पनि मापनमा गल्ती गरेको छु... यो जीवन कथाको विवरण काटिएको छ र कमेन्टमा छ। उदाहरण एकदम सामान्य छ र सिद्धान्तमा सामान्यतया एक उद्यम मा गरिन्छ जस्तै लागू, यो एकदम चाखलाग्दो भयो, यो मलाई लाग्छ, जीवन को प्रदर्शन: लेख को मुख्य विषय को गति मा प्रभाव थियो। बाह्य तर्कको कारणले ध्यान दिन योग्य छैन: Moq, Autofac, EF Core र अन्य "स्ट्र्याप"।

मैले यस लेखको छापमा काम गर्न थाले: प्रतिबिम्ब किन ढिलो छ

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

प्रतिबिम्बको गतिको बारेमा मैले सधैं समान धारणा राखेको कुरालाई ध्यानमा राख्दै, मैले विशेष गरी लेखकको निष्कर्षमा प्रश्न उठाउने उद्देश्य राखेको छैन।

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

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

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

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

यद्यपि, हामी सबैले 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;
        }

हामीले देख्न सक्छौं, सेटर गुणहरूको साथ एक स्थिर संग्रह प्रयोग गरिन्छ - संकलित lambdas जसले सेटर इकाईलाई कल गर्दछ। निम्न कोड द्वारा सिर्जना गरिएको:

        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 लाई सिधै कल गर्छौं।

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

अब BenchmarkDotNet लिनुहोस् र प्रदर्शन जाँच गरौं। र अचानक... (स्पोइलर - यो सही नतिजा होइन, विवरण तल छ)

हामी यहाँ के देख्छौं? फास्ट उपसर्गलाई जित्ने तरिकाहरू लगभग सबै पासहरूमा ढिलो उपसर्ग भएका विधिहरू भन्दा ढिलो हुन जान्छ। यो आवंटन र कामको गति दुवैको लागि सत्य हो। अर्कोतर्फ, जहाँ सम्भव भएसम्म यसको लागि अभिप्रेरित LINQ विधिहरू प्रयोग गरेर म्यापिङको सुन्दर र सुरुचिपूर्ण कार्यान्वयनले उत्पादकतालाई ठूलो मात्रामा घटाउँछ। फरक व्यवस्थाको हो। पासहरूको विभिन्न सङ्ख्यामा प्रवृत्ति परिवर्तन हुँदैन। फरक मात्र मापन मा छ। LINQ को साथ यो 4 - 200 गुणा ढिलो छ, त्यहाँ लगभग समान स्केलमा अधिक फोहोर छ।

UPDATED

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

यस्तो छ पुन: परीक्षणको नतिजा:

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

बेन्चमार्क कोड यहाँ उपलब्ध छ। जो कोहीले मेरो शब्दहरू डबल-जाँच गर्न सक्छन्:
HabraReflectionTests

PS: परीक्षणहरूमा कोडले IoC प्रयोग गर्दछ, र बेन्चमार्कहरूमा यसले स्पष्ट निर्माण प्रयोग गर्दछ। तथ्य यो हो कि अन्तिम कार्यान्वयनमा मैले प्रदर्शनलाई असर पार्ने र नतिजालाई शोरमा पार्न सक्ने सबै कारकहरूलाई काटेको छु।

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

PPPS: शैली र डिजाइनको फेदमा पुग्ने सावधानीपूर्वक पाठकलाई धन्यवाद। म एकरूपता र सुविधाको लागि छु। प्रस्तुतिको कूटनीतिले चाहिने धेरै छोड्छ, तर मैले आलोचनालाई ध्यानमा राखें। म प्रक्षेपणको लागि सोध्छु।

स्रोत: www.habr.com

प्रतिबिम्ब गति गर्ने बारे असफल लेख

एक टिप्पणी थप्न Отменить ответ