წარუმატებელი სტატია დაჩქარებული ასახვის შესახებ

მაშინვე ავხსნი სტატიის სათაურს. თავდაპირველი გეგმა იყო კარგი, სანდო რჩევის მიცემა, თუ როგორ უნდა დაჩქარებულიყო ასახვის გამოყენება მარტივი, მაგრამ რეალისტური მაგალითის გამოყენებით, მაგრამ ბენჩმარკინგის დროს აღმოჩნდა, რომ ასახვა არ არის ისეთი ნელი, როგორც მე მეგონა, LINQ უფრო ნელია, ვიდრე ჩემს კოშმარებში. მაგრამ ბოლოს აღმოჩნდა, რომ მეც შევცდი გაზომვებში... ამ ცხოვრებისეული ისტორიის დეტალები ჭრის ქვეშ და კომენტარებშია. იმის გამო, რომ მაგალითი საკმაოდ გავრცელებულია და პრინციპში განხორციელებული, როგორც ეს ჩვეულებრივ ხდება საწარმოში, აღმოჩნდა საკმაოდ საინტერესო, როგორც მეჩვენება, ცხოვრების დემონსტრირება: გავლენა სტატიის მთავარი თემის სიჩქარეზე იყო. გარეგანი ლოგიკის გამო არ შესამჩნევია: Moq, Autofac, EF Core და სხვა „სამაგრები“.

დავიწყე მუშაობა ამ სტატიის შთაბეჭდილებით: რატომ არის Reflection ნელი

როგორც ხედავთ, ავტორი გვთავაზობს შედგენილი დელეგატების გამოყენებას, ნაცვლად იმისა, რომ პირდაპირ გამოიძახოს ასახვის ტიპის მეთოდები, როგორც შესანიშნავი გზა განაცხადის მნიშვნელოვნად დაჩქარებისთვის. რა თქმა უნდა, არის IL ემისია, მაგრამ მე მსურს მისი თავიდან აცილება, რადგან ეს არის ყველაზე შრომატევადი გზა დავალების შესასრულებლად, რომელიც სავსეა შეცდომებით.

იმის გათვალისწინებით, რომ მე ყოველთვის მსგავსი აზრი მქონდა ასახვის სიჩქარის შესახებ, განსაკუთრებით არ ვაპირებდი ავტორის დასკვნების ეჭვქვეშ დაყენებას.

საწარმოში ხშირად ვხვდები რეფლექსიის გულუბრყვილო გამოყენებას. ტიპი აღებულია. ინფორმაცია ქონების შესახებ აღებულია. SetValue მეთოდი იძახება და ყველას უხარია. ღირებულება მივიდა სამიზნე ველში, ყველა ბედნიერია. ძალიან ჭკვიანი ხალხი - უფროსები და გუნდის ლიდერები - წერენ თავიანთ გაფართოებებს ობიექტზე, ასეთი გულუბრყვილო განხორციელების საფუძველზე, ერთი ტიპის მეორეზე "უნივერსალური" mappers. არსი ჩვეულებრივ ასეთია: ჩვენ ვიღებთ ყველა ველს, ვიღებთ ყველა თვისებას, ვიმეორებთ მათზე: თუ ტიპების წევრების სახელები ემთხვევა, ჩვენ ვასრულებთ SetValue-ს. დროდადრო ჩვენ ვიჭერთ გამონაკლისებს შეცდომების გამო, სადაც ვერ ვიპოვეთ რაიმე თვისება ერთ-ერთ ტიპში, მაგრამ აქაც არის გამოსავალი, რომელიც აუმჯობესებს შესრულებას. სცადე/დაიჭირე.

მე მინახავს ადამიანები, რომლებიც ხელახლა იგონებენ პარსერებსა და რუკებს ისე, რომ არ იყვნენ სრულად შეიარაღებულნი იმ ინფორმაციით, თუ როგორ მუშაობენ მათზე ადრე მოხვედრილი მანქანები. მე მინახავს ადამიანები, რომლებიც მალავენ თავიანთ გულუბრყვილო განხორციელებებს სტრატეგიების მიღმა, ინტერფეისების მიღმა, ინექციების მიღმა, თითქოს ეს ამართლებს შემდგომ ბაკანალიას. ასეთ გააზრებებზე ცხვირი ავწიე. ფაქტობრივად, მე არ გავზომე რეალური შესრულების გაჟონვა და, თუ ეს შესაძლებელია, უბრალოდ შევცვალე განხორციელება უფრო „ოპტიმალურზე“, თუკი შემეძლო ამის გაკეთება. ამიტომ, ქვემოთ განხილულმა პირველმა გაზომვებმა სერიოზულად დამაბნია.

ვფიქრობ, ბევრი თქვენგანი, რიხტერის ან სხვა იდეოლოგების კითხვისას, წააწყდა სრულიად სამართლიან განცხადებას, რომ კოდში ასახვა არის ფენომენი, რომელიც უკიდურესად უარყოფით გავლენას ახდენს აპლიკაციის შესრულებაზე.

რეფლექსიის გამოძახება აიძულებს CLR-ს, გაიაროს ასამბლეები, რათა იპოვოს ის, რაც მას სჭირდება, აკრიფოს მათი მეტამონაცემები, გააანალიზოს ისინი და ა.შ. გარდა ამისა, ასახვა მიმდევრობების გავლისას იწვევს მეხსიერების დიდი რაოდენობით გამოყოფას. ჩვენ ვიყენებთ მეხსიერებას, CLR აღმოაჩენს GC-ს და იწყება ფრიზი. შესამჩნევად ნელი უნდა იყოს, მერწმუნეთ. მეხსიერების უზარმაზარი რაოდენობა თანამედროვე წარმოების სერვერებზე ან ღრუბლოვან მანქანებზე ხელს არ უშლის დამუშავების დიდ შეფერხებებს. სინამდვილეში, რაც უფრო მეტი მეხსიერებაა, მით უფრო სავარაუდოა, რომ შეამჩნევთ როგორ მუშაობს GC. ასახვა, თეორიულად, მისთვის დამატებითი წითელი ნაწიბურია.

თუმცა, ჩვენ ყველანი ვიყენებთ IoC კონტეინერებსა და თარიღის მაპერატორებს, რომელთა მუშაობის პრინციპი ასევე ემყარება რეფლექსიას, მაგრამ, როგორც წესი, არ ჩნდება კითხვები მათ შესრულებასთან დაკავშირებით. არა, არა იმიტომ, რომ დამოკიდებულებების და აბსტრაქცია გარე შეზღუდული კონტექსტის მოდელებიდან იმდენად აუცილებელია, რომ ჩვენ უნდა შევწიროთ შესრულება ნებისმიერ შემთხვევაში. ყველაფერი უფრო მარტივია - ეს ნამდვილად არ იმოქმედებს შესრულებაზე.

ფაქტია, რომ ყველაზე გავრცელებული ჩარჩოები, რომლებიც დაფუძნებულია ასახვის ტექნოლოგიაზე, იყენებენ ყველა სახის ხრიკს, რომ უფრო ოპტიმალურად იმუშაონ მასთან. როგორც წესი, ეს არის ქეში. როგორც წესი, ეს არის გამონათქვამები და დელეგატები, რომლებიც შედგენილია გამოხატვის ხისგან. იგივე automapper ინარჩუნებს კონკურენტულ ლექსიკონს, რომელიც შეესაბამება ტიპებს იმ ფუნქციებთან, რომლებსაც შეუძლიათ ერთმანეთის გადაქცევა ასახვის გარეშე.

როგორ მიიღწევა ეს? არსებითად, ეს არაფრით განსხვავდება იმ ლოგიკისაგან, რომელსაც თავად პლატფორმა იყენებს 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();
        }

ზოგადად გასაგებია. ჩვენ გადავდივართ თვისებებზე, ვქმნით დელეგატებს მათთვის, რომლებიც იძახებენ სეტერებს და ვინახავთ მათ. მაშინ, როცა საჭიროა, ვურეკავთ.

"ნელი" (პრეფიქსი Slow კრიტერიუმებში):

        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 და შევხედოთ შესრულებას. და უცებ... (სპოილერი - ეს არ არის სწორი შედეგი, დეტალები ქვემოთ)

რას ვხედავთ აქ? მეთოდები, რომლებიც ტრიუმფალურად ატარებენ Fast პრეფიქსის, უფრო ნელია თითქმის ყველა პასში, ვიდრე მეთოდები Slow პრეფიქსით. ეს ეხება როგორც განაწილებას, ასევე მუშაობის სიჩქარეს. მეორეს მხრივ, რუკების ლამაზი და ელეგანტური განხორციელება LINQ მეთოდების გამოყენებით, სადაც ეს შესაძლებელია, პირიქით, მნიშვნელოვნად ამცირებს პროდუქტიულობას. განსხვავება წესრიგშია. ტენდენცია არ იცვლება სხვადასხვა რაოდენობის პასებით. განსხვავება მხოლოდ მასშტაბშია. LINQ-ით ის 4-200-ჯერ ნელია, დაახლოებით იგივე მასშტაბით მეტი ნაგავია.

სიახლეები

მე არ ვუჯერებდი ჩემს თვალებს, მაგრამ რაც მთავარია, ჩვენს კოლეგას არ დაუჯერა არც ჩემს თვალებს და არც ჩემს კოდს - დიმიტრი ტიხონოვი 0x1000000. ორმაგად გადაამოწმა ჩემი გამოსავალი, მან ბრწყინვალედ აღმოაჩინა და მიუთითა შეცდომა, რომელიც გამომრჩა განხორციელების მრავალი ცვლილების გამო, საწყისიდან საბოლოომდე. Moq-ის დაყენებაში აღმოჩენილი ხარვეზის გამოსწორების შემდეგ, ყველა შედეგი თავის ადგილზე დაეცა. ხელახალი ტესტის შედეგების მიხედვით, მთავარი ტენდენცია არ იცვლება - LINQ კვლავ გავლენას ახდენს შესრულებაზე, ვიდრე ასახვაზე. თუმცა, სასიამოვნოა, რომ Expression-ის კომპილაციასთან მუშაობა უშედეგოდ არ კეთდება და შედეგი ჩანს როგორც განაწილების, ასევე შესრულების დროს. პირველი გაშვება, როდესაც სტატიკური ველები ინიციალიზებულია, ბუნებრივია, უფრო ნელია „სწრაფი“ მეთოდისთვის, მაგრამ შემდეგ სიტუაცია იცვლება.

აი ხელახალი ტესტის შედეგი:

დასკვნა: საწარმოში რეფლექსიის გამოყენებისას არ არის საჭირო ხრიკების გამოყენება - LINQ უფრო მეტ პროდუქტიულობას შეჭამს. თუმცა, მაღალი დატვირთვის მეთოდებში, რომლებიც საჭიროებენ ოპტიმიზაციას, შეგიძლიათ შეინახოთ ასახვა ინიციალიზატორების სახით და დელეგირებული შემდგენელები, რაც შემდეგ უზრუნველყოფს „სწრაფ“ ლოგიკას. ამ გზით თქვენ შეგიძლიათ შეინარჩუნოთ როგორც ასახვის მოქნილობა, ასევე აპლიკაციის სიჩქარე.

საორიენტაციო კოდი ხელმისაწვდომია აქ. ნებისმიერს შეუძლია გადაამოწმოს ჩემი სიტყვები:
HabraReflectionTests

PS: ტესტებში კოდი იყენებს IoC-ს, ხოლო ბენჩმარკებში ის იყენებს აშკარა კონსტრუქციას. ფაქტია, რომ საბოლოო განხორციელებისას მე შევწყვიტე ყველა ფაქტორი, რომელიც შეიძლება გავლენა იქონიოს შესრულებაზე და შედეგი ხმაურიანი გახადოს.

PPS: მადლობა მომხმარებელს დიმიტრი ტიხონოვი @0x1000000 Moq-ის დაყენებაში ჩემი შეცდომის აღმოჩენისთვის, რამაც გავლენა მოახდინა პირველ გაზომვებზე. თუ რომელიმე მკითხველს აქვს საკმარისი კარმა, გთხოვთ მოიწონოთ. კაცი გაჩერდა, კაცმა წაიკითხა, ორმაგად გადაამოწმა და შეცდომა მიუთითა. ვფიქრობ, ეს პატივისცემის და თანაგრძნობის ღირსია.

PPPS: მადლობა ზედმიწევნით მკითხველს, რომელმაც ბოლომდე მიაღწია სტილსა და დიზაინს. მე ერთგვაროვნებისა და მოხერხებულობის მომხრე ვარ. პრეზენტაციის დიპლომატია სასურველს ტოვებს, მაგრამ კრიტიკა გავითვალისწინე. ჭურს ვითხოვ.

წყარო: www.habr.com