गतिमान प्रतिबिंब बद्दल अयशस्वी लेख

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

या लेखाच्या प्रभावाखाली मी काम करायला सुरुवात केली: परावर्तन मंद का आहे?

तुम्ही बघू शकता की, लेखक अनुप्रयोग कार्यप्रदर्शनाला लक्षणीयरीत्या गती देण्यासाठी थेट परावर्तन प्रकार पद्धतींकडे जाण्याऐवजी संकलित प्रतिनिधींचा वापर करण्याचा सल्ला देतात. अर्थात, IL उत्सर्जन देखील आहे, परंतु ते टाळणे चांगले आहे, कारण ते कार्य पूर्ण करण्याचा सर्वात श्रम-केंद्रित आणि त्रुटी-प्रवण मार्ग आहे.

परावर्तनाच्या गतीबद्दल माझे नेहमीच असेच मत आहे हे लक्षात घेता, लेखकाच्या निष्कर्षांवर प्रश्नचिन्ह उपस्थित करण्याचा माझा हेतू नव्हता.

एंटरप्राइझमध्ये मला अनेकदा रिफ्लेक्शनचे साधे वापर आढळतात. एक प्रकार घेतला जातो. प्रॉपर्टी माहिती मिळवली जाते. सेटव्हॅल्यू पद्धत कॉल केली जाते आणि प्रत्येकजण आनंदी असतो. व्हॅल्यू लक्ष्य क्षेत्रात आली आहे, प्रत्येकजण आनंदी आहे. हुशार लोक - वरिष्ठ आणि टीम लीड्स - या साध्या अंमलबजावणीवर एका प्रकारातून दुसऱ्या प्रकारात त्यांच्या "युनिव्हर्सल" मॅपरवर आधारित ऑब्जेक्ट करण्यासाठी त्यांचे स्वतःचे एक्सटेंशन लिहितात. सारांश सहसा असा असतो: सर्व फील्ड घ्या, सर्व गुणधर्म घ्या, त्यांच्यावर पुनरावृत्ती करा: जर प्रकार सदस्यांची नावे जुळत असतील, तर आम्ही सेटव्हॅल्यू कार्यान्वित करतो. जेव्हा एखाद्या प्रकारासाठी मालमत्ता सापडत नाही तेव्हा आम्ही वेळोवेळी अपवाद पकडतो, परंतु येथे देखील कामगिरी सुधारण्याचा एक मार्ग आहे: प्रयत्न करा/पकडणे.

मी लोकांना पार्सर आणि मॅपर्स पुन्हा शोधताना पाहिले आहे, त्यांना त्यांच्या आधी शोधलेल्या चाके कशी काम करतात याची पूर्ण माहिती नसतानाही. मी लोकांना त्यांचे भोळे अंमलबजावणी धोरणे, इंटरफेस आणि इंजेक्शन्सच्या मागे लपवताना पाहिले आहे, जणू काही त्यामुळे नंतरच्या गोंधळाचे निमित्त होईल. मी अशा अंमलबजावणींकडे दुर्लक्ष केले. खरं तर, मी प्रत्यक्ष कामगिरीचा ड्रेन मोजला नाही आणि जेव्हा शक्य असेल तेव्हा मी फक्त अंमलबजावणीची जागा अधिक "इष्टतम" मोजण्यासाठी घेतली. म्हणून खाली चर्चा केलेल्या सुरुवातीच्या मोजमापांनी मला गंभीरपणे गोंधळात टाकले.

मला वाटतं तुमच्यापैकी बरेच जण, रिक्टर किंवा इतर विचारवंतांचे पुस्तक वाचताना, पूर्णपणे योग्य विधानाला सामोरे गेले असतील की कोडमध्ये प्रतिबिंब ही एक अशी घटना आहे जी अनुप्रयोगाच्या कामगिरीवर अत्यंत नकारात्मक परिणाम करते.

कॉलिंग रिफ्लेक्शनमुळे 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;
        }

जसे आपण पाहू शकतो, प्रॉपर्टी सेटर्ससह एक स्टॅटिक कलेक्शन वापरले जाते—कंपाइल्ड लॅम्बडा जे एंटिटीच्या सेटरला कॉल करतात. ते खालील कोड वापरून तयार केले जातात:

        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 पट हळू असते, अंदाजे समान प्रमाणात कचरा असतो.

अद्यतनित

मला माझ्या डोळ्यांवर विश्वास बसत नव्हता, पण त्याहूनही महत्त्वाचे म्हणजे, आमच्या सहकाऱ्याला माझ्या डोळ्यांवर किंवा माझ्या कोडवर विश्वास बसत नव्हता - दिमित्री तिखोनोव्ह ०x१०००००माझ्या सोल्यूशनची पुन्हा चाचणी केल्यानंतर, त्याने सुरुवातीच्या अंमलबजावणीतील अनेक बदलांमुळे मी चुकवलेली एक त्रुटी उत्तम प्रकारे शोधून काढली आणि ती दाखवून दिली. Moq सेटअपमध्ये सापडलेल्या बगचे निराकरण केल्यानंतर, सर्व निकाल सामान्य झाले. पुन्हा चाचणी निकाल दर्शवितात की मुख्य ट्रेंड अपरिवर्तित राहिला आहे—LINQ अजूनही प्रतिबिंबापेक्षा कामगिरीवर अधिक परिणाम करते. तथापि, अभिव्यक्तींचे संकलन करण्याचे काम फायदेशीर आहे हे पाहून आनंद झाला आणि निकाल वाटप आणि अंमलबजावणी वेळेत दोन्हीमध्ये दृश्यमान आहेत. जेव्हा स्थिर फील्ड सुरू केले जातात तेव्हा पहिली धाव "जलद" पद्धतीसाठी स्वाभाविकपणे हळू असते, परंतु नंतर परिस्थिती बदलते.

येथे पुनर्परीक्षेचा निकाल आहे:

निष्कर्ष: एंटरप्राइझमध्ये रिफ्लेक्शन वापरताना, युक्त्यांचा अवलंब करण्याची गरज नाही—LINQ कामगिरी लक्षणीयरीत्या खाऊन टाकेल. तथापि, ऑप्टिमायझेशनची आवश्यकता असलेल्या उच्च-लोड पद्धतींमध्ये, रिफ्लेक्शन इनिशियलायझर्स आणि डेलिगेट कंपायलर्सच्या स्वरूपात जतन केले जाऊ शकते, जे नंतर "जलद" लॉजिक प्रदान करतील. अशा प्रकारे, तुम्ही रिफ्लेक्शनची लवचिकता आणि तुमच्या अनुप्रयोगाची गती दोन्ही जतन करू शकता.

बेंचमार्क कोड येथे उपलब्ध आहे. इच्छुक कोणीही माझे स्टेटमेंट पुन्हा तपासू शकतो:
हब्रा रिफ्लेक्शन टेस्ट्स

PS: चाचण्यांमधील कोड IoC वापरतो, तर बेंचमार्क स्पष्ट रचना वापरतात. कारण अंतिम अंमलबजावणीमध्ये, मी कामगिरीवर परिणाम करणारे आणि निकाल विकृत करणारे सर्व घटक काढून टाकले.

पीपीएस: वापरकर्त्याचे आभार दिमित्री तिखोनोव्ह @0x1000000 सुरुवातीच्या मोजमापांवर परिणाम करणाऱ्या Moq सेटअपमध्ये माझी चूक लक्षात आणून दिल्याबद्दल. जर एखाद्या वाचकाकडे पुरेसे कर्म असेल तर कृपया त्याला लाईक करा. कोणीतरी थांबले, कोणीतरी काळजीपूर्वक वाचले, कोणीतरी पुन्हा तपासले आणि चूक दाखवली. मला वाटते की हे आदर आणि सहानुभूतीला पात्र आहे.

पीपीपीएस: शैली आणि मांडणीमध्ये खोलवर लक्ष देणाऱ्या वाचकाचे आभार. मी सुसंगतता आणि सोयीसाठी आहे. सादरीकरणातील कूटनीतिमध्ये बरेच काही अपेक्षित आहे, परंतु मी टीका विचारात घेतली आहे. कृपया कामाला लागा.

स्त्रोत: www.habr.com