Rychlost ukládání

6.11.2010 8:40:46 #

Zarazil mě výsledek THashedStringListu, protože se mi zdá fakt divné, že by implementace hashovací tabulkou měla být pomalejší než implementace sekvenčním přístupem. Nemluvě o rozdílu mezi TStringListem a TMemIniFile, když, pokud si dobře vzpomínám, TMemIniFile interně používá TStringList. Tak jsem se podíval do zdrojáku:

1) Celý test je výrazně pokřivený svou metodikou: NIKDE neparsuje uložený textový soubor a dokonce ani NIKDE nezkouší jakékoliv čtení z už zparsovaných dat. Zabývá se výhradně tím, že do komponenty napumpuje spoustu záznamů a pak to celé zapíše na disk. V reálném použití ale pravděpodobně bude čtení mnohonásobně převažovat nad zápisy, zvlášť kritické pak bude prvotní rozparsování vstupu při startu aplikace.

2) Jenom taková estetická připomínka: Pořadí jednotlivých testovacích případů ve zdrojáku hodně stěžuje porovnání, proč se to chová divně.

3) Vysvětlení výsledků TStringListu a THashedStringListu je prosté: první část (vystvoření 4000 položek) je v nich udělané úplně blbě - výhodně pro rychlost, ale naprosto v nesouladu s tím, jak by se komponenty pro ukládání hodnot skutečně používaly. Mimo jiné už mě je jasné, proč je takový rozdíl mezi TMemIniFile a TStringList: zápisy typu TStringList.Add('a=b') sice probíhají v čase O(1), ale takhle se to skutečně nedá používat. Bylo nezbytné použít TStringList.Values['a'] = 'b', protože takhle bude s parametry pracovat aplikace. Nezkoušel jsem to, ale jsem si dost jistý, že za těchto okolností se vyrovná rychlost TStringListu a TMemIniFile, a pokud není implementace THashedStringListu úplně idiotská (v mých Delphi není, takže se nemůžu podívat), měl by být THashedStringList o několik řádů rychlejší než obě předchozí komponenty.

4) Podobnou unfair výhodu dostal TNativeXml - při vytváření 4000 položek se rovnou zakládají nové elementy, komponenta se vůbec nemusí zabývat otázkou, jestli náhodou už požadovaný element neexistuje a nejde tedy o UPDATE místo INSERTu (v SQL terminologii). Obě JSON komponenty se s tímhle musí vypořádat.

5) Bylo by zajímavé vyzkoušet, do jaké míry jsou dosažené časy tvořené jednotlivými kroky v benchmarku. Mám třeba vážné podezření, že se ukáže významný rozdíl v práci SuperObjectu a lkJSON čistě v tom, že v SuperObjectu se soubor zapisuje přes string -> stringstream -> filestream, zatímco v lkJSON přes string -> TStringList.Text (pomalé!! Musí se rozparsovat do jednotlivých řádků) -> TStringList.SaveToFile (pomalé!! napřed se řádky zase spojí do jednoho stringu) -> filestream. Nevidím důvod, proč se v obou případech nemohl použít stejný způsob zápisu na disk. Takhle samoúčelná změna ty výsledky dost devalvuje, protože porušuje pravidlo "za jinak stejných podmínek" - to je skoro, jako kdybych XML zapisoval na ramdisk, JSON na disketu a z výsledků usuzoval, že XML je rychlejší.

Závěr: Z takto provedeného testu NELZE NA NIC USUZOVAT, za prvé proto, že není dodržena srovnatelnost podmínek, za druhé proto, že nejsou zohledněny všechny významné skutečnosti (parsování, čtení), no a za třetí proto, že ten test se ani vzdáleně neblíží reálnému použití. (Je to asi na té úrovni, že bych srovnával výkon grafických karet s tím, že každá je strčená do jinak výkonného počítače s jiným operačním systémem a celý test byl založen na tom, že vyzkouším pomocí GDI vykreslit sto miliard vyplněných obdélníků - dá to nějaké výsledky, podle kterých jde karty seřadit, ale ty výsledky jsou nesmyslné a neplní účel testu).

pepak

6.11.2010 10:35:31 #

Nebudu se s vami hadat, na vsem bude trochu pravdy, dokonale to urcite nebude ;)

Ale tento test vychazi 100% z realnych podminek ... ve svem programu jsem potreboval 1x cist (pri startu) a zapisovat asi 100x - a asi si dovedete domyslet, co to udela za paseku, kdyz sem k tomu pouzival MemINI. To, ze jsem to mel takhle implementovany, je riziko amateru :)
Srovnatelnost neni mozna dokonala, ale zakladni predstavu o rychlostech jednotlivych trid urcite da. Za rychlosti JSON si budu stat, zadnou optimalizaci nedojde k 10nasobnemu zrychleni TStringList nebo jinych komponent tak, aby to dohnaly ;)

Problem s THashedStringList nedokazu vysvetlit, nikdy jsem ho nejak moc nepouzival a navic myslim, ze jeho implementace v Delphi neni uplne vyborna (podle toho, co jsem cetl).

Problem s TMemIniFile muze byt dan tim, ze se tam vytvari sekce, ktera pouziva THashedStringList ;)

ad 1) to je dobry napad, to bych mohl pridat
ad 2) delal jsem to puvodne pro osobni  ucely, tak ono to tam casem pribyvalo
ad 3) podivam se na to
ad 4) zkontroluji, dostuduji :)
ad 5) nad tim jsem nepremyslel, ale z neznameho duvodu SuperObject pri ukladani pres TStringList byl nejak zpomaleny, tak jsem to nahradil ...

Dekuji za vycerpavajici odezvu, najdu si odpovidajici cas a pokusim se vyladit tento test.

<z>

7.11.2010 7:54:07 #

Bohužel, námitky vůči nedodržení ceteris paribus ("za jinak stejných podmínek") trvají. Vezmu-li SuperObject jako základ:

1) lkJSON:
- Při testu zápisu nepochopitelně používá kombinaci IndexOf + Add tam, kde by měl používat "replace" (neznám přímo název metody - soudě podle zdrojáku asi nejspíš Field[...].neco). V případě tohoto testu (ale nikoliv v reálném použití!) to sice vede ke stejnému výsledku, ale jinou cestou a nedá se vyloučit, že to takhle je pomalejší.
- Test zápisu pracuje s Variantem tam, kde SuperObject pracuje se stringem.

2) NativeXml:
- Stejně jako lsJSON nepracuje s replace ale s nalezením nodu a případným vytvořením nového.

3) MSXML:
- Stejná výhrada jako u NativeXML.
- Neprovádí se u něj test aktualizace, aniž by to bylo kdekoliv zmíněno! To se nám to pak dosahuje skvělých časů...

4) THashedStringList:
- Jak říkám, neznám přesnou implementaci. Ale velice bych se divil, kdyby se to opravdu chovalo tak, jak píše Radek v komentáři ("jelikož se jedná o aktualizace dat a THashedStringList po každém přidání zneplatňuje hash tabulku") - to by signalizovalo skutečně BRUTÁLNÍ chybu v implementaci, protože u normálně implementované hashtabulky žádná taková potřeba neexistuje. Nepomohlo by třeba vhodné nastavení maximálního počtu záznamů při inicializaci tabulky?
- Nakonec si snad ten test budu muset vyzkoušet sám - ať se na to dívám jak chci, kód pro správně napsanou hash tabulku a pomocí ní implementovaný MemIniFile podle mě musí být rychlejší než jakákoliv alternativní verze včetně momentálně vedoucího JSONu - prostě proto, že bude mít nejrychlejší parsování vstupu, stejně rychlý zápis výstupu a nejrychlejší nebo přinejhorším stejně rychlé vyhledání požadovaného záznamu.

pepak

7.11.2010 11:24:14 #

problem je u tech knihoven, ze nemaj "replace" ... a ja kvuli testu ty knihovny opravdu prepracovavat nebudu, jednak protoze se mi nechce a taky protoze na to nemam potrebne znalosti ;)

- u lkJSON proste pole Field pouzit nejde, protoze tu polozku nevytvori ... tak musim pomoci IndexOf zjistit, jestli tam je (i kdyz neni, protoze to SuperObject dela) a pak pridat
- lkJSON nepracuje s variantem

- u NativeXml a MSXML to stejne, proste ty funkce jsem tam nenasel
- u MSXML je to 36 sekund ;)

- THashedStringList ma opravdu tuto brutalni chybu, trochu jsem hledal na netu a nasel jsem, ze hodne lidi si muselo udelat svoji implementaci prave kvuli tomu ...

PS: jestli najdes neco rychlejsiho, nez JSON, tak ti opravdu pogratuluji ;)

<z>

7.11.2010 11:26:36 #

aaa, moje chyba ... u MSXML jsem hledal, jak se tam pracuje s polozkama, tak jsem to okomentoval a pak na to zapmel - nic to ale nemeni na tom, ze to je strasne pomaly :D

<z>

7.11.2010 17:42:38 #

Co je mi to platné, když mám Delphi 5 :-)

pepak

7.11.2010 17:45:31 #

No hledat to nebudu, protože mě při mých počtech konfiguračních parametrů rozdíl v rychlosti ukládání nezajímá (je mi jedno, jestli to potrvá jednu milisekundu nebo deset), ale jsem si naprosto jistý, že dobře implementovaná hashtabulka bude ještě rychlejší než JSON. Prostě proto, že bude mít jednodušší parsování a jen jednu úroveň záznamů (žádný strom prvků).

pepak

7.11.2010 22:35:06 #

Jo, _v_práci_ :-)

Zítra se na to podívám, nebo si aspoň stáhnu zdroják pro prozkoumání doma, ale teď na víkend mi ta informace fakt nepomohla :-)

pepak

8.11.2010 0:09:14 #

nemuzu poprit, ze hashlist by mel byt srovnatelne rychly ... uz proto, ze JSON je jedna z takovych spravnych implementaci ;)

a nic nebrani tomu pridat do testu dalsi implementace, aby i ostatni meli prehled, jake maji moznosti

<z>

8.11.2010 8:25:41 #

Tedy skutečně zírám, jak špatně je THashedStringList napsaný. Nevěřil bych, že je něco takového možné.

pepak