Неподходяща статия за ускорение на рефлексията

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

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

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

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

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

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

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

Извикването на рефлексия принуждава 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 пъти по-бавно, а боклука е повече с приблизително същите мащаби.

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

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

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

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

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

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

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

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

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