Eba artikkel refleksiooni kiirendamisest

Selgitame kohe artikli pealkirja. Alguses oli plaanis anda head ja usaldusväärset nõu refleksiooni kasutamise kiirendamiseks lihtsa, kuid realistliku näite abil. Siiski, benchmarkimise käigus selgus, et refleksioon ei toimi nii aeglaselt, nagu ma arvasin, ja LINQ töötab aeglasemalt, kui olin unes näinud. Lõpuks selgus, et tegin mõõtmises ka vea... Selle eluloo yksikasjad on allpool ja kommentaarides. Kuna näide on üsna igapäevane ja teostatud põhimõtteliselt nagu tavaliselt ettevõttes, on tulemuseks huvitav, nagu mulle tundub, elu demonstreerimine: peamise artikli teema kiirusenäitaja ei olnud märgatav välistest loogikatest: Moq, Autofac, EF Core ja muu „ümberringi“.

Hakkasin tööd tegema selle artikli muljetest: Miks on refleksioon aeglane

Nagu näha, pakub autor kasutama kompileeritud delegaate otse refleksioonitüübi meetodite käsitlemise asemel, mis on suurepärane viis rakenduse töö kiirusel oluliselt kiirendamiseks. Seal on veel IL emissioon, kuid sellest tahaksin vältida, kuna see on kõige töömahukam viis ülesande täitmiseks, mis võib tuua kaasa vigu.

Arvestades, et olen alati arvanud, et refleksiooni kiirus on sarnane, ei kavatse ma autori järeldusi kahtluse alla seada.

Kohtan tihti naiivset refleksiooni kasutamist ettevõttes. Võetakse tüüp. Saadakse teave omadusest. Kutsutakse välja meetod SetValue ja kõik rõõmustavad. Väärtus jõudis sihitud välja, kõik on rahul. Inimesed on üsna arukad — vanemad ja tiimijuhid — kirjutavad oma laiendusi object põhiselt, tuginedes sellisele naivsele rakendusele „üldine” mappimine ühelt tüübilt teisele. Sisuliselt on see tavaliselt selline: võtame kõik väljad, võtame kõik omadused, iteratsiooni need: nimesid siiski ühtivad liikmed tüübist, teeme SetValue. Aeg-ajalt püüame erandeid seal, kus ei suudetud leida mõnda omadust üksikutest tüüpidest, kuid siin on ka väljapääs, mis parandab jõudlust. Try/catch.

Olen näinud, kuidas inimesed leiavad korduvkasutamiseks parsereid ja kaardistajaid, ilma et nad oleksid täielikult relvastatud teadmistega, kuidas varem leiutatud jalgrattad töötavad. Olen näinud, kuidas inimesed peidavad oma naiivseid teostusi strateegiate, liideste ja süstide taha, justkui see õigustaks järgnevat segadust. Selliste teostuste pärast keerutasin nina. Tegelikult ei ole ma tõelist jõudluse lekkimist mõõtnud ja võimaluse korral lihtsalt vahetasin teostust „optimaalsema” vastu, kui oli aega. Seetõttu ajasid mulle allpool mainitud esimesed mõõtmised tõsiselt segadusse.

Arvan, et paljud teist, lugedes Richterit või teisi ideoloogiaid, on kokku puutunud täiesti õigustatud väitega, et refleksioon koodis on nähtus, mis avaldab äärmiselt negatiivset mõju rakenduse jõudlusele.

Refleksioonikutsed sunnivad CLR-i käima läbi kogusid otsides vajalikke, tõmbama välja nende metaandmed, parsima neid jne. Peale selle põhjustab refleksioon järjestuste läbimisel suure hulga mälu eraldamise. Me kulutame mälu, CLR vabastab GC ja algavad häired. See peaks olema märgatavalt aeglane, uskuge. Kaasaegsete tootmisserverite või pilve masinate tohutu mälu ei päästa kõrgete viivituste eest töötlemisel. Tegelikult, mida rohkem mälu, seda suurem on tõenäosus, et te märkate, kuidas GC töötab. Refleksioon on ideeliselt tarbetu punane lipp tema jaoks.

Kuid me kõik kasutame nii IoC konteinerite kui ka andmete kaardistajaid, mille tööpõhimõte põhineb samuti refleksioonil, kuid nende jõudluse suhtes ei esita tavaliselt küsimusi. Ei, mitte sellepärast, et sõltuvuste sisestamine ja mudelitest välise piiratud konteksti abstraheerimine oleksid nii vajalikud asjad, et peame jõudluse nimel igal juhul ohverdama. Kõik on lihtsam – see ei mõjuta tõeliselt jõudlust.

Asi on selles, et kõige levinumad raamistikud, mis põhinevad refleksioonitehnoloogial, kasutavad igasuguseid nikerdusi, et paremini sellega töötada. Tavaliselt on see vahemälu. Reeglina – see on Expressions ja väljendite puust kompileeritud delegaadid. Sama automaapper hoiab enda all konkurentsi sõnaraamatut, mis seob tüübid funktsioonidega, mis saavad üksteisele konverteerida juba ilma refleksioonikutsumata.

Kuidas see saavutatakse? Põhimõtteliselt ei erine see sellest loogikast, mida platvorm ise JIT-koodi genereerimiseks kasutab. Esimese meetodi väljakutse korral kompileeritakse see (ja jah, see protsess ei ole kiire), edasiste väljakutsete korral antakse juhtimine juba kompileeritud meetodile, ja siin ei teki erilisi jõudluse langusi.

Meie puhul saab samuti kasutada JIT kompileerimist ja seejärel kasutada kompileeritud käitumist sama jõudlusega nagu AOT-analoogid. Abiks on meil antud juhul väljendid.

Lühidalt võib esitada printe, millest räägitakse, järgmiselt:
Tuleb vahemälestada refleksiooni töö lõpptulemus delegaadina, mis sisaldab kompileeritud funktsiooni. Kõik vajalikud objektid tüübi info kohta on samuti mõistlik vahemälestada teie tüübi – töötaja – objekti väli.

Selles on põhjus. Terve mõistus ütleb meile, et kui midagi on võimalik kompileerida ja vahemällu salvestada, siis peaksime seda tegema.

Edasi minnes tuleb öelda, et vahemälu refleksiooniga töötamisel on oma eelised, isegi kui ei kasuta pakutud väljenduskompileerimise meetodit. Tegelikult kordan siin autori artikli teemasid, millele viidatud.

Nüüd koodist. Vaatame näidet, mis põhineb minu hiljutisel murel, millega pidin tegelema tõsises tootmises tõsises krediidiorganisatsioonis. Kõik entiteedid on väljamõeldud, et keegi ei arvaks.

On mingi entiteet. Olgu selleks Kontakt. On kirjad standardiseeritud sisuga, millest parser ja hydrator loovad need kontaktid. Kirjaga, mis saabuva, loeme selle, jagame paarideks võtme-väärtuse, loome kontakti ja salvestame andmebaasi.

See on elementaarne. Oletame, et kontaktis on omadused Nimi, Vanus ja kontakttelefon. Need andmed saadetakse kirjas. Samuti soovib äri, et tugiteenuste töötajad saaksid kiiresti lisada uusi võtmeid entiteedi omaduste kaardistamiseks kirja kehas. Juhuks, kui keegi on malli valesti kirjutanud või kui enne väljalaskmist tuleb kiiresti stardida uue partneri kaardistus, kohandades uut formaati. Siis saame uue kaardistuskorrelatsiooni lisada kui odava andmefikse. Seega, eluline näide.

Rakendame ja loome teste. Töötab.

Ma ei too siia koodi: lähtekoodi on liiga palju ja need on saadaval GitHubis artikli lõpus antud lingil. Saate neid alla laadida, nad võivad olla teid ära tüütavad ja mõõta, kuidas see teie puhul mõjuks. Toon välja ainult kahe mallimeetodi koodi, millega erinevad kiire ja aeglane hüdraator.

Loogika on selline: mallimeetod saab paare, mis on moodustatud parseri põhiloogikast. LINQ tase on parser ja hüdraatori põhiline loogika, mis teeb päringut andmebaasi konteksti ja seondab võtmed parseri paaridega (nende funktsioonide jaoks on kood ilma LINQ-ita võrdlemiseks). Seejärel edastatakse paarid põhihüdreerimise meetodisse ning väärtused määratakse asjakohaste entiteedi omaduste järgi.

„Kiire” (prefiks Fast tulemustes):

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

Kuidas näeme, kasutatakse staatilist kogumit omaduste seadmiseks – kompileeritud lambda-funktsioone, mis kutsuvad esile entiteedi seadjat. Need luuakse järgmise koodiga:

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

Üldiselt on see selge. Läbime omadused, loome nendest delegeeritud funktsioonid, mis kutsuvad esile seadjad, salvestame. Seejärel kutsume neid välja, kui on vaja.

„Aeglase” (prefiks Slow tulemustes):

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

Siin käime kohe omadused läbi ja kutsume otse SetValue esile.

Kujutamiseks ja mõõdupuu rollis olen rakendanud naiivset meetodit, mis kirjutab paaride korrelatsiooni väärtused otse entiteetide väljadele. Eesliide – Manual.

Nüüd võtame BenchmarkDotNet'i ja uurime jõudlust. Ja äkki... (spoiler – see ei ole õige tulemus, üksikasjad allpool)

Mida me siin näeme? Meetodid, mis uhkelt kannavad eesliidet Fast, on peaaegu kõikides läbimistest aeglasemad kui meetodid, millel on eesliide Slow. See kehtib nii allokatsiooni kui ka töökiirusel. Teisest küljest, kaunis ja elegantne mapimise rakendamine, kus igal pool, kus võimalik, kasutatakse selleks ette nähtud LINQ meetodeid, vastupidi, tarbib oluliselt rohkem jõudlust. Erinevus on järsk. Suundumus ei muutu erineva läbimiste arvuga. Erinevus on vaid mõõtmetes. LINQ puhul on see 4 – 200 korda aeglasem, ja prügikogu on umbes sama suurtes mõõtmetes.

Uuendatud

Ma ei uskunud oma silmi, kuid mis veelgi olulisem, ei uskunud meie kolleeg mitte ainult minu silmi, vaid ka minu koodi — Dmitry Tikhonov 0x1000000. Kordades minu lahendust leidis ja osutas ta suurepäraselt veale, mille ma seoses mitmete muudatustega rakenduses algsest lõpuni olin unustanud. Pärast leitud vea parandamist Moqi seadistuses, seadsid kõik tulemused end õigesse kohta. Kordustestimise tulemuste põhjal ei muutu peamine suundumus — LINQ mõjutab jõudlust endiselt tugevamalt kui refleksioon. Kuid on meeldiv, et töö väljexpressiivsete väljendite kompileerimisega ei ole olnud asjatu, ja tulemus on nähtav nii allokatsioonis kui ka täitmise ajas. Esimene käivitamine, kui staatilisi välju initsialiseeritakse, on loomulikult „kiire“ meetodi puhul aeglasem, kuid hiljem olukord muutub.

Siin on kordustestimise tulemus:

Kokkuvõtteks: ettevõttes refleksiooni kasutamisel ei ole erilisi nikerdusi vaja — LINQ neelab jõudlust palju rohkem. Siiski võib kõrge koormuse meetodites, mis vajavad optimeerimist, hoida refleksiooni initsialiseerijate ja delegaatide kompilaatorite kujul, mis hiljem tagavad „kiire“ loogika. Nii saate säilitada nii refleksiooni paindlikkuse kui ka rakenduse töö kiirus.

Kood koos bänhcmariga on siin saadaval. Kõik huvilised saavad mu sõnu ümber kontrollida:
HabraReflectionTests

PS: testides kasutatav kood kasutab IoC-d, samas kui benchmarkides – selget konstruktsiooni. Asi on selles, et lõppversioonis ma kõrvaldasin kõik tegurid, mis võiksid mõjutada jõudlust ja tulemuse mürastada.

PPS: Aitäh kasutajale Dmitry Tikhonov @0x1000000 , et avastas minu vea Moqi seadistuses, mis mõjutas esimesi mõõtmisi. Kui mõnel lugejal on piisavalt karmat, siis palun nagu tema. Inimene peatus, luges süvenenult, kontrollis ja osutas veale. Ma arvan, et see on austust ja sümpaatilisust vääriv.

PPPS: aitäh sellele detailidele tähelepanelikule lugejale, kes uuris stiili ja vormingut. Ma olen järjepidevuse ja mugavuse poolt. Esituse diplomaatilisus jätab soovida, kuid ma arvestasin kriitikaga. Palun tulge siia.

Allikas: habr.com