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

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

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

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

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

Често срещам наивно използване на рефлексията в предприятието. Взема се тип. Взема се информация за свойството. Извиква се метод SetValue, и всички се радват. Стойността е стигнала до целевото поле, всички са доволни. Хората са доста интелигентни — синиори и тимлидери — пишат своите разширения на object, основавайки се на такава наивна реализация на „универсални“ мапери от един тип в друг. Сутирта обикновено е такава: вземаме всички полета, вземаме всички свойства, итериране през тях: при совпадение на имената на членовете на типа извършваме SetValue. Периодично улавяме изключения при пропуски там, където не намираме някакво свойство в един от типовете, но и тук има изход, който повишава производителността. Try/catch.

Видях как хората преоткриват парсери и мапери, без да разполагат напълно с информация как работят велосипедите, изобретени преди тях. Видях как хората крият своите наивни реализации зад стратегии, интерфейси и инжекции, все едно това ще оправдае последващата вакханалия. От такива реализации се отвращавам. Всъщност, не измерих истинския leak на производителността и, когато беше възможно, просто сменях реализацията с по "оптимална", когато стигах до нея. Затова първите измервания, за които ще говоря по-долу, сериозно ме смутиха.

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

Извикването на рефлексия принуждава CLR да обходи сборките в търсене на нужната, да извлече метаданните им, да ги парсне и т.н. Освен това рефлексията по време на обход на последователности води до алокация на голям обем памет. Изразходвайки памет, CLR активира GC и започват забавяния. Това трябва да бъде забележимо бавно, повярвайте. Огромните обеми памет на съвременни продукционни сървъри или облачни машини не спасяват от високи закъснения в обработката. Всъщност, колкото повече памет, толкова по-висока е вероятността да ЗАБЕЛЕЖИТЕ как работи GC. Рефлексията е, по идея, излишна червена кърпа за него.

Въпреки това, всички ние използваме и IoC контейнери, и дата мапери, принципът на работа на които също е основан на рефлексия, но обикновено няма въпроси за тяхната производителност. Не, не защото внедряването на зависимости и абстрахирането от модели на външен ограничен контекст са толкова необходими неща, че трябва да жертват производителността по какъвто и да е начин. Всичко е по-просто – наистина не оказват голямо влияние на производителността.

Работата е в това, че най-разпространените фреймуорци, основани на технологията на рефлексията, използват всякакви хитрости за по-оптимална работа с нея. Обикновено това е кеш. Обикновено – това са Expressions и компилирани от дърво на изразите делегати. Същият автомапер поддържа конкурентен речник, който съпоставя типове с функции, които могат да конвертират един в друг без извикване на рефлексия.

Как се постига това? По същество, то не се различава от логиката, използвана от самата платформа за генериране на JIT код. При първото извикване на метода, той се компилира (и да, този процес не е бърз), а при последващите извиквания управлението се предава на вече компилирания метод, и тук не би трябвало да има значителни спадове в производителността.

В нашия случай може да се използва също JIT компилация и след това да се използва компилираното поведение с производителност, равна на AOT аналозите. На помощ ще ни дойдат изразите.

Кратко можем да формулираме принципа, за който става въпрос, по следния начин:
Трябва да кешираме крайния резултат от работата на рефлексията под формата на делегат, съдържащ компилирана функция. Всички необходими обекти с информация за типовете също е разумно да се кешират в полета извън обектите на вашия тип – работник.

Има логика в това. Здравият разум ни казва, че ако нещо може да бъде компилирано и кеширано, трябва да го направим.

Още в напред, трябва да се каже, че кешът при работа с рефлексия има своите предимства, дори и да не се използва предложената методология за компилиране на изрази. Всъщност, тук ще повторя тезите на автора на статията, на която се позовавам по-горе.

Сега за кода. Нека разгледаме пример, който се основава на моята неотдавнашна болка, с която се сблъсках в сериозен производствен случай в сериозна кредитна организация. Всички ентити са измислени, за да не може никой да познае.

Има някаква същност. Нека е Contact. Има писма със стандартизирано съдържание, от които парсерът и хидраторът създават тези контакти. Получихме писмо, прочетохме го, разбихме на двойки ключ-стойност, създадохме контакт и го запазихме в базата данни.

Това е елементарно. Да предположим, че контактът има свойства Име, Възраст и телефонен номер. Тези данни се предават в писмото. Също така, бизнесът иска, за да могат поддръжките да добавят нови ключове за отразяване на свойствата на ентити на двойки в съдържанието на писмото. За всеки случай, ако някой е допуснал грешка в шаблона или ако преди релиза трябва спешно да се активира отразяване от нов партньор, адаптирайки се към новия формат. Тогава новата корелация на отразяването можем да добавим като евтин датафикс. Тоест, пример от живота.

Реализираме, създаваме тестове. Работи.

Кода няма да представя: изходниците станаха много, и са достъпни в GitHub на линка в края на статията. Можете да ги изтеглите, да ги модифицирате до неузнаваемост и да измерите как това би се отразило на вашия случай. Ще представя само кода на два шаблонни метода, с които хидраторът, който трябваше да бъде бърз, се различава от хидатора, който трябваше да бъде бавен.

Логиката е следната: шаблонният метод получава двойки, формирани от базовата логика на парсера. Нивото на LINQ е парсерът и базовата логика на хидратора, която прави запитване към базата данни и съпоставя ключовете с двойките от парсера (за тези функции има код без LINQ за сравнение). След това двойките се предават на основния метод за хидратиране и стойностите на свойствата се задават на съответните свойства на ентитито.

"Бърз" (префикс Fast в бенчмарковете):

 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 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>)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.

За по ясност и като еталон реализирах наивен метод, който записва стойностите на техните корелационни двойки директно в полетата на ентити. Префикс – Manual.

Сега взимаме BenchmarkDotNet и изследваме производителността. И внезапно… (спойлер — това не е правилният резултат, подробности — по-долу)

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

UPDATE

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

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

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

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

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

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

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

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