Podtitulek tohoto logu se zmiňuje o tom, že bych se zde rád věnoval střípkům z konferencí o .NETu. Dlouho jsem váhal, zda téma, které mě trklo, bude zajímavé. Ale poté, co jsem si vše vyzkoušel a napsal test, neváhal jsem.

Informace o tom, že použití reflection je pomalejší, je obecně známý fakt, se kterým jsem pracoval. Ovšem výsledky měření, které jsem provedl, mě celkem překvapily. Ale vrátím se na samý začátek, ať nevytvářím závěry dřív, než napíšu podstatu.Jeden z dotazů do konference zněl, zda se dá ze zadaného jména proměnné, k této přistoupit a změnit její hodnotu.

On ten dotaz zněl ještě přesněji. Což mě vedlo k odpovědi, proč raději nepoužít pole. Tomas Rampas však neváhal a odpověděl, přesně podle přání dotazujícího. V ten okamžik mě napadlo, že ve svých programech používám reflection, a uživatelsky definované atributy. Zatím jsem však neprováděl měření, kterým bych zjistil k jak velkému zpomalení, díky tomuto přístupu, vše vede. Takže jsem neváhal a zkusil napsat pár tříd, na kterých jsem si chtěl ověřit onen obecně známý fakt.

Definice testování

Ač jsem absolvoval nějaké pokusy (jistě je znáte i vy ze školních škamen), jedna z mála věcí, která mi utkvěla v paměti je, že se má testovat na stejném vzorku dat. Takže jsem definoval množinu, vlastně třídu, která bude mít možnost uchovat sto hodnot typu int. K těmto hodnotám se půjde dostat pomocí metod int GetValue(int index) a void SetValue(int index, int value). Pro lepší porovnání jsem pak přistoupil ještě k možnosti, že třídy, které používají reflection, si mohou informativní údaje uschovat do HashTable. Co mě napadlo až při pohledu na kód zaslaný do příspěvku, že vytvořím ještě třídu, která bude obsahovat property, místo fieldů.

Jak jsem měřil

Mám připravené čtyři třídy, které jsem pojmenoval TestArray, TestField, TestProperty a TestPropertyHash. Každá obsahovala zmíněné dvě metody. Přistup k hodnotám pole byl realizován s otestováním na přetečení a přistupu nad/pod mez pole. Ostatní tři třídy přistupovaly ke svým property/fields pomocí reflection. Veřejné proměnné byly pojmenovány Cislo0 .. Cislo99. Z předaného čísla indexu byl sestaven název proměnné a pomocí reflection získáno PropertyInfo/FieldInfo. Rozdíl byl u testování TestPropertyHash, kdy se nejdříve zjišťovala přítomnost informací v tabulce a až poté jsem případně zjišťoval potřebné informace.Po několika měřeních jsem zjistil, že simulovat aspoň trochu reálné prostředí zřejmě nepůjde, neboť naměřené hodnoty jsou příliš malé pro posouzení náročnosti. Takže jsem nastavil počet průchodů přes jednotlivé operace na poněkud vyšší hodnoty, než které se mohou (snad) reálně vyskytnout v aplikaci. I když ani takové chování se nemůže nikdy vyloučit. Takže nakonec jsem přistoupil k následujícím počtům.

• Start počítání času
• Vytvoření objektu celkem 20x
• Počet zapsání a opětovné vyzvednutí hodnoty každé proměnné v jednom vytvořeném objektu 50x
• Ukončení počítání času

Malé doplnění k měření

Jelikož jsem byl při znalosti naměřených hodnot zvědavý, co s metodami GetProperty a GetField udělají zapsané BindingFlags, pustil jsem měření ještě jednou s uvedením těchto Flagů BindingFlags.Public | BindingFlags.Instance. V tabulce jsou tato měření označena jako "O".

Výsledky měření

Jak už jsem se zmínil v úvodu, měřeními jsem byl celkem překvapen, i když musím říci, že se jedná o trošku přehnané hodnoty průchodů, a ať jsem vzpomínal jak chtěl, nenarazil jsem na případ, kdy bych něco takového ve svých aplikacích prováděl. Každopádně je to zajímavé a pokud někdo uvažuje o co nejrychlejším kódu, určitě bych doporučoval se reflection vyhnout. Měření ukázalo, že nejpomalejší přístup je pomocí reflection, která získává informace o veřejných Fieldech. Za ní se v těsném závěsu drží přístup k Property. O něco lepší je přístup, kdy se použije k uchování informací Hashtable, která pak udržovala celkem konstantní čas přístupu a je to asi nejrozumější volbou, pokud je potřeba použít reflection. Samozřejmě nejrychlejší cestou je pak přímý přístup k poli, který měl v prvních chvílích až nezanedbatelné měření. Ostatně kvůli tomu, jsem zvedal "laťku" výše, abych se ujistil, že takové měření nemá spíše statistickou chybu. Jak měření dopadla, se můžete přesvědčit v následující tabulce.

Ještě je potřeba zmínit, že pro měření jsem nakonec využil kódu, který uveřejnil Petr Lazecký.

Tabulka naměřených hodnot

Poohlédnutí se za výsledkem

Myslím, že k tomuto není třeba dodávat jakýchkoli slov. Čísla jsou jasná. Naměřenými hodnotami jsem byl překvapen víc, a očekával jsem o hodně menší rozdíly. Obzvláště mě pak překvapil rozdíl v přístupu k Property a Field. Můj osobní předpoklad byl spíše opačný na druhou stranu je to jen dobře, neustále zjišťuji, že se mám co učit a co zkoušet.

Budu rád, za jakékoli Vaše připomínky, které mohou pomoci nejen mě, ale i ostatním.