Hogyan készítsünk többet a net_graph-t

Optimalizálás .Nettó alkalmazások: kis szerkesztések nagy eredménye

Ma látni fogjuk, hogy a megfelelő helyszíneken a kis optimalizációk növelik teljesítményét. Eltávolítottam egy extra iterátor létrehozását egy helyen, megszabadult a csomagolásról a másikban, és végül kimutatja az eredményt, a szerkesztésekkel szemben.

A teljes cikken keresztül a piros szálat egy egyszerűvé teszi, bár nem egy új gondolat, amit kérem, hogy emlékezzen.

Korai optimalizálás – gonosz.

Hadd magyarázzam. Ez megtörténik, hogy az optimalizálás és az olvashatóság egy kicsit különböző irányban megy. A kód optimálisan működhet, de nehezebb elolvasni és fenntartani. És fordítva – a kód könnyen olvasható és módosítható, de vannak problémák a teljesítmény. Ezért fontos megérteni, hogy mit akarsz áldozni egy vagy más módon.

Elolvashatja a cikket, rohanás a kód adatbázisának szerkesztéséhez és … Ne kapjon teljesítményteljesítmény javítását. De a kódod összetettebb lesz.

Ezért (és azonban jobb), hogy hideg fejjel múljon. Nagy, ha ismeri az alkalmazás szűk keresztmetszeteit, ahol az optimalizációk képesek lesznek segíteni. Ha még nem ismeri ezeket a helyeket, különféle profilizátorok jönnek a mentéshez. Nagy mennyiségű információt adhatnak az alkalmazásról. Különösen, hogy leírja a viselkedése dinamika: milyen típusú másolat jön létre legfőképpen, hogy mennyi ideig tart a kérelmet a szemetet összeszerelés, milyen hosszú egy-egy töredéke a kódot, és t.Ns. Itt szeretném dicsérni két Jetbrains eszközöket: Dottrace és Dotmemory. A velük való munka kényelmes, és általában intuitív módon érthető, sok információ van, kiváló vizualizált. Jetbrains hűvös!

De hátra közelebb optimalizálásainkhoz. A cikk során több olyan esetet elemezünk, amelyekkel szembe kellett néznem, és ez a legérdekesebbnek tűnt nekem. A leírt változások mindegyike pozitív eredményt adott, mivel a profilizátorok által megjelölt alkalmazás keskeny helyén készült. Sajnos nem maradtam meg az egyes szerkesztések teljesítményének megváltoztatásának eredményei, de az optimalizálás általános eredménye a cikk végén kerül sor.

jegyzet. Ez a cikk beszél a munkával .NET Framework. Mint gyakorlati bemutatók (lásd. Példa a Habhcode-val), néhány pillanatban az azonos kód kódja a C # alatt .Nettó mag / .A nettó lehet optimálisabb, mint az alatta .NET Framework.

És mi, valójában optimalizálja?

A cikkben leírt tippek mindenki számára relevánsak .Net alkalmazások. Természetesen, ahogy fent írtam, különösen hasznos kódok lesznek, amikor az alkalmazás keskeny helyén készültek.

Azonnal meg akarom jegyezni, hogy nem vezetünk néhány absztrakt elméleti érvelést. Oly módon, hogy a Lélek tippjei “Módosítsa a kódot, hogy megmentse az egyik ITATOR létrehozását”, amennyire csak lehetséges. A mai napról beszélő problémák azonosítják a statikus PVS-Studio analyzer profiljának eredményeit a c # c #. A profilalkotás fő célja az elemzési idő csökkentése volt.

A munka megkezdése után gyorsan világossá vált, hogy az analizátor nagy problémái vannak a szemétgyűjtéssel: jelentős időt foglalt. Tény, hogy korábban tudtuk, csak egyszer gondoltuk. By the way, számos elemző optimalizáció történt korábban, amelyről külön cikk van.

Mindazonáltal a probléma még mindig releváns volt.

Nézd meg az alábbi képernyőképet (Teljes méretű kép itt). Ez a PVS-stúdió C # elemző eredménye, amelyet egy projekt elemzése során kaptunk. 8 sáv – 8 szál, amelyet az analizátor használta. Amint látható, mindegyik patakban az idő jelentős részét a szemétgyűjtő munkája foglalja el.

A tippek dobása, hogy mindent átírjunk C-re, elkezdtünk tanulmányozni a részletesebb információkat a profilozás eredményeiről és a felesleges / ideiglenes tárgyak létrehozásának megszüntetésére. Örömünkre, egy ilyen megközelítés azonnal elkezdett gyümölcsöt adni.

Valójában ezen a témában, és a fő hangsúlyt ma meg fogják tenni.

Milyen nyereményeket sikerült elérni? Határozottan elmondom róla, de megnyomom az intrigát a cikk végéig.

Hívási módszerek paramer-paraméterrel

Módszerek az aláírásban, amelynek jele paraméternek minősül, mivel a megfelelő argumentum:

• Ne vegyen értékeket;
• Vegyünk egy vagy több értéket.

Például egy ilyen aláírással rendelkezünk:

Nézzük meg az IL kód bemutatását:

Amint láthatjuk, ez egy egyszerű módszer egy paraméterrel, amelyet a habrayahattribute attribútum jelölt. A paraméter típusának, az általunk megadott sor tömb.

Érdekes tény. Nem lehet közvetlenül használni ezt az attribútumot – a fordító CS-hibát ad, és használja a Params kulcsszót.

Az adott IL kódból nagyon egyszerű következtetést kell követni – minden alkalommal, amikor meg kell hívnunk ezt a módszert, amely hívja, hogy a kódot előre hozzon létre egy tömböt. Majdnem.

Ahhoz, hogy jobban foglalkozzunk azzal, hogy mi történik, amikor ezt a módszert különböző érvekkel hívja, fontolja meg a konkrét példákat.

Első hívás érvek nélkül.

IL kód:

Amint emlékszem, a módszer elvárja a bejáratra vonatkozó tömböt, ezért valahol el kell vinni. Ebben az esetben a statikus módszer Habt> hívásának eredményét érvként használják. A HABT> segítségével lehetővé teszi az üres gyűjtemények megteremtését, és ennek következtében csökkenti a GC terhelését.

És most egy kanál. A fordító régebbi verziója egy másik IL kódot generálhat. Például:

Ebben az esetben minden egyes módszerhívás esetén, ha nincs megfelelő argumentum a Params paraméterhez, új üres tömböt hoz létre.

Adózási idő az önellenőrzéshez. Ha a következő két hívás megkülönböztethető, ha igen -?

Ha már válaszoltál erre a kérdésre, értsük meg.

Kezdjük a hívással, ha az argumentum egyértelmű null:

IL kód:

Ebben az esetben a tömb létrehozása nem fordul elő. A null értékét egyszerűen érvként továbbítják.

Most vegye figyelembe az esetet, ha a nem null értéket továbbítják a módszerre:

IL kód:

Amint látható, a kód itt több, mint a korábbi példákban. A módszer hívása előtt létrejön egy tömb. A Paramer paraméternek megfelelő módszer összes argumentumát ebben a tömbben rögzítik. Ebben az esetben a tömb csak rögzül – egy üres karakterlánc.

Felhívjuk figyelmét, hogy ha több érv, egy tömb is létrejön, akkor is, ha az érvek explicit érték NULL.

Így a parament paraméterekkel rendelkező módszerekkel kapcsolatos felhívások a tömbök implicit megteremtése miatt. Bizonyos esetekben például megfelelő érvelés hiányában és egy modern fordító használatával optimalizálható. De általában érdemes emlékezni az ideiglenes tárgyakról.

Az elemző profilalkotás, találtam több helyen, ahol a Profiler kiderült létrehozása számos tömbök gyorsan nyomja a szemetet szerelvény.

A megfelelő módszereknél a következő típusú kód volt:

Az Iskindequal módszer maga is így nézett ki:

A fentiekben szétszerelt elméletből következik, hogy hívja a módszert, amire szükségünk van egy tömb létrehozásához. Maga a tömb csak akkor használható, amelyek utána nem szükséges.

Lehetséges, hogy megszabaduljon a felesleges tömbök létrehozásáról? Alapvető:

Az ilyen elemi szerkesztés segített csökkenteni az átmenetileg létrehozott tömbök számát, és ennek következtében csökkenti a GC terhelését.

jegyzet. Könyvtárakban .Net néha okozó recepciót használ. Néhány parament paraméterrel rendelkező módszerek is túlterhelések is vannak, amelyek a Params paraméter helyett a megfelelő típusú paraméter 1, 2, 3-at vesznek fel. Ezzel elkerülhető az ideiglenes tömbök létrehozásának a hívóból.

Habt>

Többször a profilozás eredményeiben bármilyen módszerrel villogott. Mi a gond vele? Egy igazi kód alapján fogjuk megérteni – már említettük az Iskindequal módszert. Korábban inkább a paraméterekre összpontosítottunk. Most tekintse meg részletesebben a módszer módszerét belülről.

Ahhoz, hogy megértsük, mi a probléma bármilyen, meg kell néznie a “Hood alatt” módszer. A forráskód a kedvencéből származik

A forrásgyűjtemény egyszerűen az AREACH ciklusban változik. És ha legalább egy elemes hívás predikátum visszatért valódi érték, akkor a módszer eredménye igaz, ellenkező esetben – hamis.

A fő probléma az, hogy minden bemeneti gyűjtemény pontosan értelmezhető, mint az eleumerable>, és nincsenek optimalizálása bizonyos típusú gyűjteményekhez. Hadd emlékeztessem arra, hogy a vizsgált ügyben egy tömbben dolgozunk.

A szakértők már kitalálták, hogy a legfontosabb probléma bármilyen – egy felesleges iterátor létrehozása a kollekcióhoz. Ha nem igazán érti, mi a probléma, ne aggódj, most meg fogjuk érteni.

Vágja le az összes módszer extra fragmenseit, és egyszerűsítse azt, mentse el az USA-hoz szükséges alapkódot: a ciklus bejelentése és a gyűjtemény bejelentése, amellyel a ciklus működik.

Ennek eredményeként fontolja meg az ilyen kódot:

Megfelelő IL kód:

Ahogy láthatod, sok dolog van. Mivel a fordító nem tud semmit arról, hogy a tényleges típus bemutatja a gyűjteményt, általános kódot hoz létre, hogy megkerülje a gyűjteményt az iterátoron keresztül. Az iterátor megszerzése a GetTenumator módszerrel történik (IL_ Label). Az iterátor megszerzése egy tömb (saját esetünk esetében), ha a Getenumerator módszert hívja a getenumerator módszer létrehozásához egy objektum egy halom, és a gyűjtemény összes további kölcsönhatása az objektum használatára épül.

jegyzet. A fordító speciális optimalizálást alkalmazhat, ha egy iterátort kap egy üres tömbhöz. Ebben az esetben a Getenumerator hívás nem vezet új objektum létrehozásához. De róla, talán, valahogy külön jegyzetet írok. Általánosságban elmondható, hogy nyilvánvalóan nem érdemes számolni az ilyen optimalizálásra.

Most változtassa meg a kódot egy kicsit úgy, hogy a fordító pontosan tudja, mit dolgozunk egy tömbben. A C # kód így fog kinézni:

A megfelelő IL kód:

Ebben az esetben, amikor a fordító pontosan tudja, milyen gyűjteményt dolgozunk, sokkal egyszerűbb kódot generált. Különösen az egyetlen iterátorral való munka eltűnt – még az objektum sem létrejön (csökkentjük a terhelést a GC-n).

By the way, itt van egy kérdés az önellenőrzésre. Ha visszaállítja ebből a C # kódkódból, a nyelv nyelvét a végén kapja meg? Amint látja, ez a kód nagyon különbözik attól, amit korábban előállított a foreach ciklushoz.

Figyelem, válasz.

Az alábbi módszerre a C # -n belül ugyanazt az IL kódot generálják, mint a fentiek szerint (a nevek kivételével):

Így, amikor a fordító tudja, hogy egy tömbben dolgozunk, optimális kódot generál, megnyitja a foreach hurkot, mint a.

Sajnos, ha bármilyen, esetünket használunk, elveszítjük az ilyen optimalizálást, valamint hozzon létre egy extra iterator objektumot, hogy megkerülje a szekvenciát.

Lambda kifejezések

A Lambda nagyon kényelmes dolog, ami nagymértékben megkönnyíti az életet. Természetesen, míg valaki nem vagy valaki, aki úgy dönt, hogy átmászik a lambda-n keresztül a lambda belsejében, a lambda … szerelmesek csinálni, vegye fel, komolyan.

Általánosságban elmondható, hogy a lambda kifejezések használata jelentősen leegyszerűsíti az életet. De ne felejtsük el, hogy a kapucnis alatt a lambda kiderül az egész osztályok. Ennek eredményeként az ilyen osztályok esetei még mindig meg kell teremteniük.

Forduljunk vissza az iskindequal módszerrel.

És most nézze meg a megfelelő IL kódot:

Egyetértek, a kód itt egy kicsit több, mint a c #. Azok a pillanatok, amelyeket most már meg kell jegyezni, itt kettő az első esetben az IL_ és IL_ címkék objektumok létrehozására irányuló utasítások, az első esetben a Típus-fordító által automatikusan létrehozott objektum (mi fekszik a Hood “lambda kifejezések alatt). Második hívás NewOBJ – Egy küldöttség létrehozása, amely az ISKIND ellenőrzését végzi.

Érdemes megjegyezni, hogy egyes esetekben a fordító optimalizálást alkalmazhat, és nem adhatja hozzá a NewoBJ utasításokat a generált típus példányának létrehozásához. Ehelyett például egyszer létrehozhat egy objektumot, rögzítse azt egy statikus mezőbe, és továbbra is dolgozik ezzel a mezővel. Ilyen viselkedés figyelhető meg, például ha nincsenek rögzített változók a lambda kifejezésben.

Megfelelte az Iskindequal verzió

Ahogy láttuk, néhány ideiglenes tárgyat hozunk létre az ISKINEQAL minden egyes hívására. És, mint a gyakorlat azt mutatja (és profil), bizonyos esetekben játszhat szerepet tárgyi szempontból terhelés GC.

Az egyik lehetőség – a módszer használatának megtagadása. Ahogy láttuk, a hívó többször is hívhatja az ISKIND módszert. Egy másik lehetőség – írja át a kódot.

A “UP-ig” verzió így néz ki:

Ez az, hogy az egyik lehetséges verziója úgy néz ki:

jegyzet. Kívánt esetben a kódot újraírhatjuk a foreach segítségével. Amint korábban megjegyeztük, amikor a fordító tudja, hogy pontosan dolgozunk egy tömbvel, még mindig létrehoz egy IL cikluskódot a motorháztető számára.

Ennek eredményeképpen egy kicsit több kódot kiderült, de megszabadultunk az ideiglenes tárgyak létrehozásáról, amelyek korábban áttekintették. Meg tudod győződni arról, hogy az IL kódra néztem – az összes NewoBJ utasításai eltűntek.

Az alapvető módszerek felülbírálása jelentős típusokban

Minta kód a maghoz:

Mit gondolsz, hogy az adott kód megadja-e a terhelést a GC-n? Nos, oké, figyelembe véve azt a tényt, hogy a kód ebben a cikkben van, a válasz nyilvánvaló.

Hittel? Tény, hogy nem olyan egyszerű. A kérdés megválaszolásához tudnia kell például, hogy az alkalmazás alatt működik-e .Nettó keretrendszer vagy .Háló. Az úton, hol lehet a terhelés a GC-n? Úgy tűnik, hogy nincsenek objektumok a szabályozott halomban.

Hogy megértsem a témát, hogy meg kellett néznem az IL-t, és a specifikáció olvasható. Részletesebben kiderült egy külön cikkben.

Ha dióhéjban van, itt van spoilerek:

• Itt a csomagolás előfordulhat, hogy hívja a gethashcode módszert;
• A csomagolás elkerülése érdekében az értelmes típusok alapvető módjaiban.

A gyűjtemények kezdeti tartályainak beállítása

Hallottam a következő véleményről: “Igen, miért kell beállítani a gyűjtemény kezdeti tartályát, a motorháztető alatt minden optimalizálva van”. Természetesen valami optimalizálva van (pontosan mit fogunk látni). De ha beszélünk ezeken a helyeken az alkalmazás, ahol a teremtés szinte minden tárgy tud repülni egy fillért sem, akkor nem szabad elhanyagolni a lehetőséget, hogy azonnal azonnali alkalmazása, a gyűjtemény, amely mérete van szükségünk.

Arról, hogy miért hasznos a kezdeti kapacitás beállítása, beszéljünk a Listt típusú példaként>. Tegyük fel, hogy van a következő kód:

Nyilvánvaló, hogy mi az ilyen kód problémája? Ha igen, megnyomom a kezét. Ha nem, semmi szörnyű, most meg fogjuk érteni.

Tehát üres listát hozunk létre, és fokozatosan kitöltjük. Ennek megfelelően, minden alkalommal, amikor a lista listája véget ér, szükségünk van:

• Válassza ki a memóriát egy új tömbhöz, amelyben a lista elemei összecsukhatók;
• Másolja át a régi tömb elemeit az újban.

Ahonnan a tömb? Ez áll a középpontjában a Listt> típusú, tudjuk, hogy minden rendben van ugyanazon az HAB

Nyilvánvaló, hogy minél nagyobb a változók gyűjteményének mérete, annál több ilyen művelet lesz végrehajtva.

Algoritmus a lista növekedéséhez a mi esetünkben (a verzióhoz) .Net Framework) a következők: 0, 4, 8, 16, 32 … vagyis ha a változókészítmények gyűjtése esetén 8 tömbök és 7 másolási műveletek létrehozása szükséges.

Mindezek a felesleges költségek elkerülhetők, ha azonnal beállítja a lista kezdeti tartályát:

Elhanyagolt egy ilyen lehetőség egyértelműen.

Linq: Egyéb

Habt>

A HAB módszer a túlterhelés függvényében:

• Számítsa ki a gyűjtemény elemeinek számát;
• Számítsa ki a predikátum kielégítő gyűjteményének elemét.

Ezenkívül számos optimalizációt hajtanak végre a módszer belsejében, de … van egy árnyalat.

Kezdjük el a módszert bejutni. A szokásos módon

Ez az, amit a verzió nem veszi igénybe:

És így – a predikátummal rendelkező változat:

Jó hír: A módszer nélküli módszer alkalmazásában van egy optimalizálás, amely lehetővé teszi, hogy hatékonyabban kiszámítsa az icollekció vagy az icollectiont végrehajtó gyűjtemények számát.

Ha azonban nem így van, akkor az egész gyűjtemény várhatóan megkapja az elemek számát. Ez különösen érdekes a predikátum módszer keretében.

Tegyük fel, hogy van a következő kód:

És ugyanakkor a gyűjteményben – elemek. Látod, igen? Annak érdekében, hogy ellenőrizze ezt az állapotot, elég lenne számunkra, hogy megtaláljuk a 13 elemet, amelyekre a predikátum (elem) igaz lenne. Ehelyett azonban a predikátumot a gyűjtemény összes elemére alkalmazzák. Különösen szégyen lesz, ha a predikátum viszonylag nehéz műveletet hajt végre.

Van egy kiút – kerékpár! Az analóg / számláló analógok írása értelmében. Mi a teendő a módszerek aláírása (és hogy tegye őket egyáltalán) – dönteni. Egyszerűen készíthet több különböző módszert, akkor egy módszert hozhat létre egy ravasz aláírással, amelyen keresztül meg kell határozni, hogy melyik összehasonlításra van szükség (‘>’, ”, ‘==’ és T. D.). Ha hirtelen kiderítetted a számhoz kapcsolódó szűk keresztmetszeteket, hanem az egész házassági helyeket – egyszerűen átírhatja őket, hogy használják a foreach ciklust, például.

Bármely -> szám / hossz

Fentebb már szétszerelt, hogy a hívás az eljárás bármely tehet nekünk egy felesleges bejáró. A felesleges objektum létrehozása elkerülhető, ha az adott gyűjtemények tulajdonságait használja, például a listt>.Számoljon vagy rossz.

Például:

Az ilyen kód kevésbé rugalmasabb, lehet, hogy kicsit rosszabb, de lehetővé teheti az iterátor létrehozását. Igen, tud. Ez attól függ, hogy az új objektum visszatér-e a Getenumerator által. A kérdés finomabb tanulmányozásával olyan érdekes pillanatok, amelyeket egy külön jegyzetben lehet leírni.

LINQ -> Ciklusok

Mivel a gyakorlat azt mutatja, azokon a helyeken, ahol minden átmeneti létrehozott objektum ronthatja a teljesítményt, akkor van értelme, hogy hagyjon fel a LINQ javára egyszerű ciklusokat. Beszéltünk róla, hogy bármelyik példáján, ugyanazon történet és más módszerekkel beszéltünk.

Csak például:

Ez a kód átírható például az alábbiak szerint:

Bár ez egy nagyon egyszerű eset, ahol a különbség nem különösebben látható, vannak olyanok, ha a LINQ kérések sokkal könnyebbek, mint a hasonló kódexek. Tehát ismét emlékeztetlek téged arra, hogy ez csak annyira, hogy megtagadja a Linq-t – a kétséges ötlet.

jegyzet. Ha elfelejtette, mert a Linq, az objektumok megjelenhetnek a kezelt halomban, azt javaslom, hogy kapcsolatba léphessen ezzel a videóval vagy ezzel a cikkkel.

Bufferizációs LINQ kérések

Ne felejtsük el, hogy a halasztott számítással kapcsolatos LINQ lekérdezések minden alkalommal újra végrehajtásra kerülnek, amikor egy sorozatot futtatnak.

Példa egyértelműen bemutatva:

Ebben az esetben a HARGINGHTRUE módszer 15-szer kerül végrehajtásra. Ugyanakkor, ha van egy kérésű pufferelésünk (hozzáadta a Tolist módszert a LINQ kihívásokhoz való híváshoz), a mindig csak 5-szerese.

A szemétgyűjtés mód megváltoztatása

Fent már említettem, hogy a korábbi már megtettük számos optimalizációt a C # analizátor PVS-Studio, sőt írtam ezt a cikket. Miután megjelent a Hab-n, aktív vita kezdődött a megjegyzésekben. Az egyik javaslat megpróbálta megváltoztatni a szemétgyűjtő beállításait.

Nem azt mondani, hogy nem tudtuk róluk. Ráadásul, amikor optimalizálódtam, és olvastam az “Alkalmazási alkalmazások optimalizálása a platformon .Net “, majd olvassa el a GC beállításokat is. Azonban valahogy nem tudta felzárkózni a szemétgyűjtési rezsim megváltoztatását. Ajtófélfa.

Ennek eredményeképpen, miközben nyaraltam, kollégáim nagyon kompetens dolgot tettek: megragadta a megjegyzések tanácsát, és úgy döntött, hogy megpróbálja kísérletezni a GC működésének megváltoztatásával. Az eredmény lenyűgöző volt – az elemzési idő a nagy projektek (például Roslyn) PVS-studio C # segítségével jelentősen csökkent. Ugyanakkor a memóriafogyasztás növekedett a kis projektekben, de megengedett határértékekben.

Például, a gépen, ahol a kísérletet végezték, az idő elemzés az eredeti kódot, az azonos Roslyn -kal csökkent 47 százalékkal! Ha korábban a projekt elemzése 1 óra 17 perc alatt zajlott, majd a szemétgyűjtési mód megváltoztatása után, Roslyn 41 percen belül kezdett megtörténni.

A Roslyn elemzés pszichológiai védjegye 1 órán belül nagyon szép volt.

Annyira elégedettek voltak azzal az eredményekkel, amellyel új (kiszolgáló) szemétgyűjtő módot tartalmaztak a C # analizátorban. A PVS-Studio verzióból ez az üzemmód alapértelmezés szerint engedélyezve lesz.

A szemétgyűjtési módok különböző módjai Szergej Teplyakov ebben a cikkben ismertetett.

P.S. By the way, Sergey – a csodálatos könyv “platform tervezési mintái .HÁLÓ “. Ha hirtelen nem olvasták, erősen ajánlom.

Optimalizálási eredmények C # PVS-Studio Analyzer

A fent tárgyalt optimalizálás mellett számos másot tettünk.

Például:

• A szűk keresztmetszetek megszüntetése bizonyos diagnózisban (egy és teljesen átíródott);
• Az adatáramlás elemzésében használt létesítmények optimalizálása: a másolás megkönnyítése, további. gyorsítótárazás, ideiglenes tárgyak eltávolítása a kezelt halomba;
• Optimalizálási összehasonlítás fa csomópontok;
• stb.Ns.

A lebontott optimalizálást elkezdték hozzáadni a PVS-stúdióhoz a kiadással és fokozatosan hozzáadva. Ugyanakkor nem szabad elfelejtenünk, hogy ebben az időben az analizátor új diagnosztikával, támogatással van kitöltve .Nettó 5 projektek, és az elemzés.

A szórakozás érdekében az elemzési idő nyílt forráskódú projekteket mértem a PVS-stúdió 2 verziójával, a statisztikai és a leghosszabb elemzett projektekhez.

Az alábbi grafikonon láthatja az elemzés időpontját (percekben):

• Projekt Juliet Test Suite;
• Roslyn projekt;
• A tesztek összes projekt teljes elemzése.

Magátaga:

Amint látható, a teljesítménynövekedés nagyon jelentősnek bizonyult. Tehát, ha hirtelen megpróbálta a C # elemző PVS-stúdiót, és elégedetlen maradt a munkájának sebességével, azt javaslom, hogy megpróbálom újra próbálni. By the way, a megadott linken kaphat egy kiterjesztett próbai engedélyt – nem 7, és 30 napig. 😉

Ha most találkozik néhány problémával, győződjön meg róla, hogy támogatja a támogatást, meg fogjuk érteni.

Következtetés

Korai optimalizálás – gonosz. Hosszú élési optimalizálás profilozáson alapul! És ne feledje, hogy a többszörös végrehajtható kódban is nagyon kicsi változások jelentősen befolyásolhatják az alkalmazás teljesítményét, ha a megfelelő helyeken készült.

Mint mindig, meghívlak, hogy feliratkozzam a Twitteremre, hogy ne hagyj ki érdeklődést.

Ha meg szeretné osztani ezt a cikket angolul beszélő közönséggel, kérem, hogy használja a fordításhoz: Sergey Vasiliev. Optimalizálása .Net alkalmazások: kis szerkesztések nagy eredménye.