Неуспешна статия за ускоряване на размисъл

Веднага обяснявам заглавието на статията. Първоначалният план беше да се даде добър, надежден съвет за ускоряване на използването на отражение, като се използва прост, но реалистичен пример, но по време на сравнителния анализ се оказа, че отражението не е толкова бавно, колкото си мислех, LINQ е по-бавен, отколкото в кошмарите ми. Но в крайна сметка се оказа, че и аз съм сгрешил в мерките... Подробности за тази житейска история има под изрезката и в коментарите. Тъй като примерът е доста обикновен и се прилага по принцип, както обикновено се прави в едно предприятие, се оказа доста интересна, както ми се струва, демонстрация на живота: въздействието върху скоростта на основния предмет на статията беше не се забелязва поради външна логика: Moq, Autofac, EF Core и други "ремъци".

Започнах да работя под впечатлението от тази статия: Защо Reflection е бавен

Както можете да видите, авторът предлага използването на компилирани делегати вместо директно извикване на методи от тип отражение като чудесен начин за значително ускоряване на приложението. Разбира се, има IL емисия, но бих искал да я избегна, тъй като това е най-трудоемкият начин за изпълнение на задачата, която е изпълнена с грешки.

Като се има предвид, че винаги съм бил на подобно мнение за скоростта на размисъл, нямах особено намерение да поставям под въпрос изводите на автора.

Често срещам наивно използване на отражение в предприятието. Типът е взет. Взета е информация за имота. Извиква се методът SetValue и всички му се радват. Стойността е пристигнала в целевото поле, всички са доволни. Много умни хора - възрастни хора и ръководители на екипи - пишат своите разширения към обект, базирайки се на такава наивна реализация „универсални“ преобразуватели от един тип в друг. Същността обикновено е следната: вземаме всички полета, вземаме всички свойства, итерираме ги: ако имената на членовете на типа съвпадат, изпълняваме 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;
        }

Както виждаме, използва се статична колекция със свойства на сетер - компилирани ламбда, които извикват обекта на сетер. Създаден от следния код:

        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 и да разгледаме производителността. И изведнъж... (спойлер - това не е правилният резултат, подробностите са по-долу)

Какво виждаме тук? Методи, които триумфално носят префикса Fast, се оказват по-бавни в почти всички проходи от методите с префикс Slow. Това важи както за разпределението, така и за скоростта на работа. От друга страна, красивото и елегантно внедряване на картографиране с помощта на LINQ методи, предназначени за това, където е възможно, напротив, значително намалява производителността. Разликата е от ред. Тенденцията не се променя с различен брой пасове. Единствената разлика е в мащаба. С LINQ е 4 - 200 пъти по-бавно, има повече боклук приблизително в същия мащаб.

АКТУАЛИЗИРАН

Не повярвах на очите си, но по-важното е, че нашият колега не повярва нито на очите ми, нито на кода ми - Дмитрий Тихонов 0x1000000. След като провери повторно моето решение, той брилянтно откри и посочи грешка, която пропуснах поради редица промени в изпълнението, от начални до крайни. След коригиране на открития бъг в настройката на Moq, всички резултати си дойдоха на мястото. Според резултатите от повторния тест основната тенденция не се променя - LINQ все още влияе повече върху производителността, отколкото отражението. Хубаво е обаче, че работата с компилацията на Expression не е напразна и резултатът е видим както в разпределението, така и във времето за изпълнение. Първото стартиране, когато се инициализират статичните полета, естествено е по-бавно за „бързия“ метод, но след това ситуацията се променя.

Ето резултата от повторния тест:

Заключение: когато използвате отражение в предприятие, няма особена нужда да прибягвате до трикове - LINQ ще изяде повече производителността. Въпреки това, в методите с високо натоварване, които изискват оптимизация, можете да спестите отражение под формата на инициализатори и делегатни компилатори, които след това ще осигурят „бърза“ логика. По този начин можете да поддържате както гъвкавостта на отражението, така и скоростта на приложението.

Кодът за бенчмарк е достъпен тук. Всеки може да провери отново думите ми:
HabraReflectionTests

PS: кодът в тестовете използва IoC, а в бенчмарковете използва изрична конструкция. Факт е, че при окончателното изпълнение отрязах всички фактори, които биха могли да повлияят на производителността и да направят резултата шумен.

PPS: Благодаря на потребителя Дмитрий Тихонов @0x1000000 за откриването на грешката ми при настройването на Moq, която повлия на първите измервания. Ако някой от читателите има достатъчна карма, моля, харесайте го. Човекът спря, човекът прочете, човекът провери отново и посочи грешката. Мисля, че това е достойно за уважение и съчувствие.

PPPS: благодарение на щателния читател, който стигна до дъното на стила и дизайна. Аз съм за еднообразие и удобство. Дипломатичността на презентацията оставя много да се желае, но взех критиката предвид. Питам за снаряда.

Източник: www.habr.com