Неуспешна статија за забрзување на рефлексијата

Веднаш ќе го објаснам насловот на статијата. Оригиналниот план беше да се даде добар, сигурен совет како да се забрза користењето на рефлексијата користејќи едноставен, но реален пример, но за време на бенчмаркингот се покажа дека рефлексијата не е толку бавна како што мислев, LINQ е побавен отколку во моите кошмари. Но, на крајот испадна дека и јас згрешив во мерењата... Детали од оваа животна приказна се под рез и во коментар. Бидејќи примерот е прилично вообичаен и имплементиран во принцип како што обично се прави во претпријатието, се покажа како доста интересна, како што ми се чини, демонстрација на животот: влијанието врз брзината на главната тема на статијата беше не се забележуваат поради надворешната логика: Moq, Autofac, EF Core и други „ремени“.

Почнав да работам под впечатокот на оваа статија: Зошто Рефлексијата е бавна

Како што можете да видите, авторот предлага користење на компајлирани делегати наместо директно повикување методи за тип на рефлексија како одличен начин за значително забрзување на апликацијата. Се разбира, има емисија на 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