Misslyckad artikel om att påskynda reflektion

Jag ska genast förklara artikelnamnet. Det var ursprungligen tänkt att ge ett bra och pålitligt råd för att påskynda användningen av refleksion genom ett enkelt, men realistiskt exempel. Men under benchmarking visade det sig att refleksion inte är så långsam som jag trodde, medan LINQ är långsammare än jag drömde i mardrömmar. Slutligen visade det sig att jag också hade gjort ett misstag i mätningarna... Detaljer om denna livshistoria under inlägget och i kommentarerna. Eftersom exemplet är ganska vardagligt och genomfört på det sätt som vanligen görs i enterprise, blev det en intressant demo av livet, tycker jag: påverkan på hastigheten av huvudsakligt ämne i artikeln var inte märkbar på grund av extern logik: Moq, Autofac, EF Core och annan

Jag började mitt arbete inspirerad av denna artikel: Varför är refleksion långsam

Som man kan se föreslår författaren att använda kompilerade delegater istället för direkt åtkomst till metoder från reflektionsklasser som ett utmärkt sätt att kraftigt påskynda applikationens prestanda. Det finns förstås också IL-emission, men den skulle jag vilja undvika eftersom det är det mest resurskrävande sättet att utföra uppgiften, vilket medför risk för fel.

Med tanke på att jag alltid har haft en liknande uppfattning om reflektionshastighet hade jag inte tänkt ifrågasätta författarens slutsatser.

Jag stöter ofta på naiv användning av refleksion i enterprise. Man tar en typ. Man tar information om en egenskap. Metoden SetValue anropas, och alla är glada. Värdet skickas till det målade fältet, alla är nöjda. Människor är ganska intelligenta – seniorer och teamledare – skriver sina egna utvidgningar på object baserat på en sådan naiv implementering av 'universella' mapper från en typ till en annan. Oftast är det så här: vi tar alla fält, vi tar alla egenskaper, itererar genom dem: vid överensstämmelse av medlemsnamn utför vi SetValue. Ibland fångar vi undantag på missar där vi inte hittade någon egenskap i en av typerna, men även här finns det en lösning som förbättrar prestandan. Try/catch.

Jag har sett hur människor återuppfinner parsers och mappers utan att vara helt informerade om hur de cyklar som redan finns fungerar. Jag har sett hur människor döljer sina naiva implementationer bakom strategier, bakom gränssnitt, bakom injektioner, som om det skulle ursäkta den efterföljande kaoset. Jag vände mig bort från sådana implementationer. I själva verket har jag inte mätt den verkliga prestandaförlusten, och när jag haft möjlighet har jag helt enkelt ändrat implementeringen till en "mer optimal", om jag haft tid. Därför förvirrade mig de första mätningarna som nämns nedan allvarligt.

Jag tror att många av er, när ni läser Richter eller andra ideologer, har stött på det fullt rimliga påståendet att reflektion i kod är ett fenomen som har en extremt negativ påverkan på applikationens prestanda.

Reflektionsanrop tvingar CLR att genomsöka assemblyer på jakt efter den nödvändiga, hämta deras metadata, parsa dem osv. Dessutom leder reflektion under sekvensgenomgångar till att stora mängder minne allokeras. När vi använder minne, aktiverar CLR GC och frizarna börjar. Detta bör vara märkbart långsamt, tro mig. Stora mängder minne på moderna produktionsservrar eller molnmaskiner räddar inte från höga latenser i behandlingen. Faktum är att ju mer minne, desto större är sannolikheten att du kommer att LÄGGA MÄRKE TILL hur GC fungerar. Reflektion är, i teorin, en onödig röd trasa för den.

Ändå använder vi alla både IoC-containrar och datamappers vars funktionsprincip också bygger på reflektion, men vi har vanligtvis inga frågor kring deras prestanda. Nej, inte för att beroendeinjektion och abstraktion från modeller i en begränsad extern kontext är så nödvändiga att vi måste offra prestanda i vilket fall som helst. Det är enklare – de påverkar faktiskt inte prestandan särskilt mycket.

Det handlar om att de mest utbredda ramverken som bygger på reflektionsteknologi använder olika trick för att arbeta mer optimalt med den. Oftast handlar det om cache. Vanligtvis – det är Expressions och de delegerade som kompilerats från expressionsträdet. Denna automapper har en tråd-säker ordbok som kopplar typer till funktioner som kan konvertera en till en annan utan att kalla på reflektion.

Hur uppnås detta? I grunden skiljer det sig inte från logiken som plattformen själv använder för att generera JIT-kod. Vid första anropet av metoden kompileras den (och ja, denna process är inte snabb), vid efterföljande anrop överförs kontrollen till den redan kompilera metoden, och här kommer det inte att vara några större fall i prestanda.

I vårt fall kan vi också dra nytta av JIT-kompilering och sedan använda det kompilera beteendet med samma prestanda som dess AOT-motsvarigheter. I detta fall kommer uttryck att hjälpa oss.

Principen som diskuteras kan kort sammanfattas på följande sätt:
Det är viktigt att cachelagra det slutliga resultatet av reflektionsarbetet i form av en delegat som innehåller den kompilera funktionen. Alla nödvändiga objekt med typinformation bör också cachas i fält som sparas utanför objekten i din typ – workern.

Det finns logik i detta. Sunt förnuft säger oss att om något kan kompileras och cachas, är det bäst att göra det.

För att gå framåt bör det nämnas att cache i arbete med reflektion har sina fördelar, även utan att använda den föreslagna metoden för uttryckskompilering. Egentligen kommer jag här att upprepa författarens punkter från artikeln som jag hänvisade till ovan.

Låt oss nu prata om koden. Låt oss betrakta ett exempel som baseras på en nyligen upplevd smärta som jag stött på i en seriös produktion hos en seriös kreditorganisation. Alla entiteter är fiktiva, så att ingen kan gissa.

Det finns en viss entitet. Låt oss kalla den Kontakt. Det finns e-postmeddelanden med en standardiserad kropp, från vilka parsern och hydratorn skapar dessa kontakter. Ett meddelande kom in, vi läste det, delade upp det i par av nyckel-värde, skapade en kontakt och sparade den i databas.

Detta är elementärt. Anta att kontakten har egenskaperna Namn, Ålder och kontakttelefon. Dessa uppgifter överförs i meddelandet. Företaget vill också att supporten snabbt ska kunna lägga till nya nycklar för att mappa egenskaperna hos entiteten mot par i meddelandets kropp. För de fall någon gjort ett skrivfel i mallen eller om det innan lanseringen snabbt behöver starta mappningen av en ny partner, anpassa sig till det nya formatet. Då kan vi lägga till den nya mappningskorrelationen som en billig datafix. Det vill säga, ett verkligt exempel.

Vi genomför och skapar tester. Det fungerar.

Jag kommer inte att ge koden: det blev många källfiler och de är tillgängliga på GitHub via länken i slutet av artikeln. Du kan ladda ner dem, trötta ut dem till oigenkännlighet och mäta hur detta skulle påverka ditt fall. Jag ger bara koden för två mallmetoder som skiljer sig åt mellan hydratorn som skulle vara snabb och hydratorn som skulle vara långsam.

Logiken är följande: mallmetoden får par formade av den grundläggande logiken i parsern. LINQ-nivån är parsern och den grundläggande logiken i hydratorn som gör en förfrågan till databasens kontext och matchar nycklar med paren från parsern (det finns kod utan LINQ för dessa funktioner att jämföra). Därefter skickas paren till huvudmetoden för hydrering och värdena för inställningen tilldelas motsvarande egenskaper hos entiteten.

"Snabb" (Prefixet Fast i benchmarken):

 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;
        }

Som vi kan se används en statisk samling med property-setters – komplierade lambdauttryck som anropar setter för entiteten. Dessa skapas med följande kod:

        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();
        }

Övergripande är det klart. Vi går igenom egenskaperna, skapar delegater för dem som anropar setters, sparar dem. Sedan anropar vi dem när det behövs.

"Långsam" (Prefixet Slow i benchmarken):

        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;
        }

Här går vi direkt igenom egenskaperna och anropar SetValue direkt.

För tydlighetens skull och som referens har jag implementerat en enkel metod som skriver värdena av deras korrelationspar direkt i entitetsfälten. Prefixet är – Manual.

Nu tar vi BenchmarkDotNet och undersöker prestandan. Och plötsligt… (spoiler – detta är inte rätt resultat, detaljer nedan)

Vad ser vi här? Metoder som stolt bär prefixet Fast visar sig nästan under alla försök vara långsammare än metoder med prefixet Slow. Detta gäller både allokering och hastighet. Å andra sidan, den vackra och eleganta implementeringen av mappning med användning av LINQ-metoder där det är möjligt, äter faktiskt upp prestandan. Skillnaden är stor. Trenden förändras inte med olika antal genomgångar. Skillnaden ligger bara i skalorna. Med LINQ är det 4 – 200 gånger långsammare, med mer skräp i ungefär samma skala.

UPPDATERAD

Jag trodde inte mina ögon, men vad viktigare är, varken mina ögon eller min kod trodde vår kollega – Dmitry Tikhonov 0x1000000. Genom att dubbelkolla min lösning upptäckte han briljant och pekade på det fel som jag missade på grund av en rad förändringar i implementeringen från början till slut. Efter att ha åtgärdat den påträffade buggen i Moq-inställningen, föll alla resultat på plats. Vid resultatet från retestet förändras inte den grundläggande trenden – LINQ påverkar fortfarande prestandan mer än reflektion. Men det är trevligt att arbetet med kompilering av uttryck görs utan anledning, och resultatet syns både i allokering och under körningstid. Den första körningen, när de statiska fälten initieras, är därmed logiskt långsammare för den "snabba" metoden, men situationen ändras därifrån.

Här är resultatet av retestet:

Slutsats: Vid användning av reflektion i företagslösningar krävs inte några särskilda knep – LINQ kommer att sluka prestandan mer. Ändå, i högbelastade metoder som kräver optimering, kan reflektion sparas i form av initialiserare och kompilatorer av delegationer, som sedan kommer att säkerställa "snabb" logik. Så kan du både bevara flexibiliteten hos reflektion och hastigheten på applikationens arbete.

Koden med benchmarken finns här. Alla intresserade kan dubbelkolla mina ord:
HabraReflectionTests

PS: koden i tester använder IoC, medan den i benchmarkar använder explicit konstruktion. Anledningen är att jag i den slutliga implementationen har tagit bort alla faktorer som kan påverka prestanda och förstöra resultatet.

PPS: Tack till användaren Dmitry Tikhonov @0x1000000 för att upptäcka mitt misstag i inställningen av Moq, vilket påverkat de första mätningarna. Om någon av läsarna har tillräckligt med karma, ge honom gärna en like. Personen stannade, läste noggrant, dubbelkollade och påpekade misstaget. Jag anser att det är värt respekt och sympati.

PPPS: tack till den noggranna läsaren som klagade på stilen och utformningen. Jag förespråkar enhetlighet och bekvämlighet. Diplomatin i presentationen lämnar en del att önska, men jag har tagit till mig kritiken. Jag ber om er förståelse.

Källa: habr.com