Během vývoje naší interní aplikace v Avastu jsme museli řešit nejeden problém s výkonem. Vždy jsme postupovali tak, že jsme nějakým způsobem změřili výkonnost aplikace a až na základě toho dělali příslušná opatření – a takový přístup bych doporučil vždy – nemá moc cenu odhadovat, co by asi tak mohlo stát za neuspokojivou výkonností, nejlepší je to změřit. Samozřejmě jsou ale vyložené boty, kterých se je třeba vyvarovat vždy. V tomto článku bych rád ukázal pár zajímavých triků pro vyšší výkonnost, které rozhodně nešlo jen tak vykoukat z kódu.

Naše aplikace je ale opravdu hodně zatížená, takže pravděpodobně většinu z těchto triků nikdy nebudete potřebovat. Na druhou stranu, výkonu je dneska sice dost, ale v okamžiku, kdy máte třeba aplikaci v cloudu a účtování podle spotřeby CPU, mohou se výkonností optimalizace vyplatit.

Volba datových typů

Zdálo se nám, že je naše aplikace docela žravá na RAMku, takže jsem na ni pustili memory profiler, který ukázal, že máme alokováno strašně moc stringů, přičemž drtivá většina z nich má velikost 64 znaků. Nebylo divu – v naší aplikace pracujeme se soubory a jako unikátní identifikátor používáme SHA256 hash jeho obsahu. Tento hash máme reprezentovaný vlastní vymazlenou třídou Sha256, která má vnitřně uloženou hodnotu jako string (vždy o velikosti 64 znaků). Rozhodnutí reprezentovat vnitřní stav stringem nemělo žádné opodstatnění – prostě to bylo první, co nás napadlo. Kdybych věděl, že budeme mít v aplikaci obrovské pole Sha256, tak bych o tom začal uvažovat a zamyslel jsem nad tím víc, ale protože jsou Sha256 rozšířené po celé aplikaci…
Takže řešení? Použít místo stringu (vždy o velikosti 64) byte[] (vždy o velikost 32). A poučení pro příště? Pokud je velká pravděpodobnost, že vznikne fakt hodně instancí nějakého typu, vyplatí se přemýšlet o velikosti tohoto objektu.

Nevěřte knihovnám

Už jsem řešil takových problémů s velmi rozšířenými knihovnami, že nevěřím ničemu, ani třídám přímo z .NETu – potenciální zdroje problémů si proklepávám přes ILSpy. I standardní knihovny .NETu implementují jen lidé.
Jednoznačně největším zklamáním pro mě byla implementace metody GetHashCode pro pole. Ale pěkně od začátku.
Při zkoumání obsahu paměti naší aplikace jsme zjistil, že něco smrdí okolo instancí Dictionary<Sha256, T> – viděl jsem, že tam jsou dlouhé lineární seznamy bucketů, což ukazovalo na problém v hashovací funkci (velké množství kolizí). Na tento problém ukazovaly i testy výkonnosti, protože bylo vidět, že se tráví docela dost času při prostém čtení z Dictionary (i v řádu jednotek milisekund!).
Naše třída Sha256 měla metodu GetHashCode() implementovanou tak, že se pouze volalo GetHashCode() na poli bajtů, které reprezentuje vnitřní stav. Ale hledat chybu v samotném .NETu? Nu nakonec se vyplatilo. Zjistil jsem, že u polí se hash počítá jen z posledních 8 prvků pole, což by bylo pravděpodobně ok. Větší problém je to, že to není naimplementované korektně a ve for cyklu indexují místo i pomocí 0. Takže se hash počítá jen z jednoho prvku pole, což u pole bajtů znamená, že v dictionary vznikne max. 256 bucketů. Nakonec jsem zjistil, že nejsem sám, kdo si tohoto problému všiml. Řešení bylo prosté a výkonnostní efekt okamžitý – upravili jsme metodu GetHashCode() třídy Sha256 tak, aby se počítalo se všemi prvky pole. Možná by stálo za zkoumání, jestli by v našem případě (vždy 32 prvků pole) nestačilo iterovat přes menší počet prvků, ale čtení z Dictionaries je nyní prakticky neměřitelné (vzhledem k náročnosti okolního kódu), takže jsme to dál neřešili.

Fakt nevěřte knihovnám

Hodně cachujeme. Víceméně to máme implementované tak, že máme dekorátory, do kterých si necháme injectovat naše jednoduché rozhraní IObjectCache, které má metody Get, Set, Remove – nic složitého. Konkrétní používaná implementace pak používala standardní ASP.NET cache. Cachujeme fakt masivně, takže nebyl problém mít v cache desítky, stovky milióny záznamů (o velikosti desítek GB). No ale když jsem viděl, že čtení z této cache je občas pomalejší než čtení přímo z databáze, musel jsem se podívat této standardní cache na střívka. A zabrečel jsem. Vytvoří se jen pár hashmap (násobky počtu procesorů), do kterých se to snaží všechno nasoukat. Takže následovala implementace vlastní in-memory cache.

Už vůbec nevěřte open-source knihovnám

Používáme databázi Postgres a z .NETu k ní přistupujeme pomocí standardního driveru Npgsql. Performance profiling ale ukázal, že se tráví hrozně moc času při vybírání connection z poolu. Při pohledu na kód přes ILSpy (na originální zdrojáky se nedá koukat) jsem se zhrozil – každé vybrání z libovolného connection poolu znamená lock. Máme docela dost databázových serverů (řekněme >10) a hodně čilý traffic, a když se lockuje na objektu sdíleném všemi (!) pooly…no comment.
Nejelegantnější řešení by bylo upravit přímo knihovnu Npgsql, ale celý projekt je tak strašně zprasený, že jsme to raději vyřešili tak, že jsme connection pooling v Npgsql vypnuli a implementovali si vlastní (pěkně transparentně pomocí dekorátoru, tj. změna na úrovni konfigurace).

ASM FTW!

Je zřejmé, že každá úroveň abstrakce si nějaký výkon vezme, a někdy se tak může vyplatit v kritických částech programu sestoupit o úroveň níže.
V Postgres používáme datový typ hstore (hashmapa), který při čtení dostáváme jako string, který je třeba naparsovat. To jsme dělali elegantně pomocí regulárního výrazu. Základní pravidla pro používání třídy Regex jsou jasná – stačí vytvořit jednu instanci (jedná se o immutable třídu) a nezapomenout specifikovat RegexOptions.Compiled. Ale u nás bylo i takovéto použití příliš pomalé (jak ukázalo měření).
Třída Regex funguje tak, že si vytvoří stavový automat, pomocí kterého pak provádí požadované operace. Sestoupení o úroveň níže tedy znamenalo napsat si automat pro daný regulární výraz ručně. A vyplatilo se!

Takže rada na závěr? Pište čistý kód a až pak měřte, měřte, měřte! A pokud to vypadá, že je problém v nějaké frikulínské knihovně, tak i tuhle eventualitu prověřte.