NotORM je rychlejší než Doctrine 2 i Dibi

Školení, která pořádám

Patrik Votoček srovnal rychlost a paměťovou náročnost několika ORM a porovnal je s hodnotami knihovny Dibi. Bohužel do srovnání nezahrnul moji knihovnu NotORM, která se dá použít místo ORM. Naštěstí ale testovací kód publikoval, takže jsem testy mohl zopakovat a rozšířit je o NotORM. Výsledek mě po pravdě řečeno ani příliš nepřekvapil.

Čas (ms)

Testovala se rychlost provedení čtyř základních operací (metodika je popsaná v původním článku). Já jsem srovnal z mého pohledu zajímavé knihovny Dibi, Doctrine 2 a NotORM:

Knihovnaselectinsertupdatedelete
Dibi1617.242134.966428.421249.887
Doctrine 21390.539457.234755.267403.661
NotORM706.752134.887128.954160.803

graf

Paměťová náročnost (kB)

Knihovnaselectinsertupdatedelete
Dibi6600.9724920.0874925.6324877.281
Doctrine 29439.3507056.5547102.9587005.480
NotORM10866.8554174.8094395.3364144.314

graf

Vyšší paměťová náročnost při získávání dat je způsobena tím, že NotORM nedovoluje určit třídu objektů načítaných z databáze (vždy je to NotORM_Row). V testu se tedy nejdříve vytvoří objekt této třídy a pak objekt třídy používané v testu. V reálných podmínkách by vytváření tohoto druhého objektu bylo zbytečné.

Použitá konfigurace

Závěr

Na rychlosti a ještě spíše na paměťové náročnosti knihoven podle mě nijak zvlášť nezáleží, pokud se neliší asymptoticky. Test navíc nijak nepokrýval oblasti, ve kterých je NotORM obzvlášť silné (efektivní získávání vztahů a přenášení jen těch sloupců, které se nakonec skutečně využijí). Je ale potěšující, že zdaleka nejpříjemnější syntaxe NotORM je zároveň spojena s nejvyšší rychlostí.

Zdrojové kódy jsem publikoval na GitHubu.

Jakub Vrána, Seznámení s oblastí, 27.7.2010, diskuse: 19 (nové: 0)

Diskuse

zřejmě povinné:

Přijde jen mě nevhodně zvolený druh grafu?
Jestliže uvádím několik hodnot například bez závislosti na času, tak mi příde nevhodné je takto propojovat a využil bych spíše klasické sloupcové grafy.

ikona Jakub Vrána OpenID:

Souhlasím, že typ grafu není úplně nejvhodnější. Použil jsem tento typ proto, že ho používá původní článek, takže se čtenáři mohou snadněji zorientovat a hodnoty porovnat.

ikona Joelp:

Navíc graf nemá popsané osy, takže je tak či tak na nic. Že je to v tabulce nic neomlouvá.

LamiCZ:

"V reálných podmínkách by vytváření tohoto druhého objektu bylo zbytečné"
OK, IMHO by to chtělo udělat ty paměťové nároky bez toho 2. objektu. 

LamiCZ:

Jeste abych doplnil - SELECTy se v praxi pouzivaji nejvice, proto mne to zajima.

ikona Ondrej Mirtes:

Za efektivitu a rychlost NotORM ti rozhodne patri uznani, ale tento test je michani hrusek s jablky. Dibi, Doctrine i NotORM jsou tri diametralne rozdilne nastroje, ktere slouzi k jinym ucelum. Dibi je obalka nad databazi, do ktere vyvojar zadava dotazy tak, jak je on sam navrhne. Doctrine je primarne nastroj na persistenci objektu modelu do databaze a NotORM je ciste jen generator co nejrychlejsich a nejuspornejsich SQL dotazu. Uz jen z tohoto hrubeho popisu se da odhadnout, jak test dopadne a ze nema moc smysl ho delat :) Kazdy z tech nastroju se hodi na neco jineho a divat se jen na rychlosf pri praci s databazi by bylo kratkozrake.

Omlouvam se za absenci diakritiky, pisu to z mobilu.

ikona Patrik Votoček:

Tento test je skutečně tak trochu míchání jablek s hruškami. Nicméně tento tes neměl za úkol nic jiného než vizualizovat skutečnost. Vzhledem k tomu, že se mě u prvního projektu zdála Doctrine 2 doopravdy hodně pomalá.

Navíc tento test měl být jednou polovinou odpovědi na nejčastější dotazy, které na mě směřují od programátorů v Nette Frameworku. A sic "Jakou zvolit databázovou vrstvu?" tedy to M z MVP(C) u Nette aplikací. A ano skutečně spousta lidí, kteří tyto otázky pokládají, ta první polovina odpovědi na tuto otázku moc nezajímá (to jaké jsou mezi nimi rozdíly).

NoxArt:

Vzhledem ke spoustě práce co má Doctrine oproti zbývajícím navíc (prostě je ORM) tak z pohledu D2 tenhle test dopadl naopak velmi dobře...

Škoda že tu není DBAL...

ikona Jakub Vrána OpenID:

Když se na to podíváme obecněji, tak všechno to jsou nástroje pro získávání a ukládání dat do databáze. A při řešení této úlohy lidi zvažují, které řešení použijí. Já třeba neznám situaci, kdy by se NotORM nehodilo použít (a zastánci Doctrine nebo Dibi jistě mohou říct skoro to samé).

Osobně mě překvapilo, že Dibi není nejlepší ani rychlostně, ani paměťově. Od knihovny na nejnižší úrovni bych to čekal.

milan:

nejvíce mě zarazilo, že oproti původnímu testu jsou poměry dibi/doctrine naprosto odlišné.

ikona Jakub Vrána OpenID:

Asi ses špatně koukal, stejné křivky v grafech vypadají velmi podobně.

ikona v6ak:

Při bližším zkoumání mě jedna věc zarazila: Dibi je u MySQL prý rychlejší než PDO (psal kdysi David Grudl), tuším kvůli nevhodné implementaci parametrizovaných dotazů v MySQL. NotORM využívá PDO a je rychlejší než Dibi.
Jak je to možné, pokud bylo použito MySQL? Pro Dibi bylo použito PDO? Asi ano. Mohla by to také být odpověď na dotaz od Milana.
Jinak Dibi se mi jako low level až tak nejeví, ono to parsuje ten Dibi dialekt SQL.
Je teď otázka, co považovat za spravedlivé. Pokud všechny knihovny použijí stejné API k databázi, bude se měřit hlavně rychlost kódu okolo. Samozřejmě, svoji roli může ve složitějších případech hrát nemalou mírou i vhodné položení dotazu, pokud to je v moci dané knihovny.
Na druhou stranu, pokud budeme srovnávat snadno dosažitelný výkon pod MySQL, bylo by to nefér vůči Dibi.

ikona Jakub Vrána OpenID:

PDO je pomalé při použití nativního vázání proměnných. To se dá pomocí PDO::MYSQL_ATTR_DIRECT_QUERY vypnout, v novějších verzích to tak je i defaultně. NotORM navíc vázání proměnných často ani nepoužívá a data ošetřuje na straně PHP samo (stejně jako Dibi). Bylo tomu tak i v tomto testu.

Test pro Dibi použil driver MySQLi: http://github.com/Vrtak-CZ/ORM-benchmark/…/config.ini.

ikona v6ak:

Aha, takže s tímto nastavením bude asi rychlost PDO, mysql a mysqli podobná. Pak se testuje jen rychlost toho kódu okolo, popř. jeho schopnost položit vhodný dotaz. A pak taky je ten dobře dosažitelný výkon někde jinde.

ikona David Grudl:

Díval jsem se, že pro testování dibi se používá DibiFluent zápis. Ten považuji spíš za "akademický" a nebyl dosud nijak zvlášť optimalizován pro výkon (výkon = nepoužívat fluent). Pokud fluent zápis nahradíte za klasické dibi::query(), naměřené časy se srovnají s NotORM. Zdrojové kódy na http://github.com/dg/ORM-benchmark/tree/dibi

Tudíž NotORM není rychlejší než dibi.

ikona v6ak:

Zajímavá poznámka. Ale řekl bych, že k NotORM je podobnější spíše DibiFluent.

msx:

Niekde som čítal, že porovnanie NOTORM a Doctrine 2 je dosť subjektívne a že nepoukazuje na hlavnú výhodu 5 dielneho modelu Doctrine 2. O 5 dielnom modeli som síce niečo čítal, ale nepochopil som to. Nechce sa ti o tom napísať článok?

Miloš Brecher:

Knihovna NotORM podle dokumentace neumí INSERT, UPDATE ani DELETE, přesto jsou u NotORM uvedeny časy na tyto operace - něco jsem přehlédl?

Miloš Brecher:

Aha, špatně jsem četl dokumentaci - ona NotORM umí i INSERT, UPDATE i DELETE - https://php.vrana.cz/co-je-noveho-v-notorm.php

Diskuse je zrušena z důvodu spamu.

avatar © 2005-2024 Jakub Vrána. Publikované texty můžete přetiskovat pouze se svolením autora. Ukázky kódu smíte používat s uvedením autora a URL tohoto webu bez dalších omezení Creative Commons. Můžeme si tykat. Skripty předpokládají nastavení: magic_quotes_gpc=Off, magic_quotes_runtime=Off, error_reporting=E_ALL & ~E_NOTICE a očekávají předchozí zavolání mysql_set_charset. Skripty by měly být funkční v PHP >= 4.3 a PHP >= 5.0.