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:
| Knihovna | select | insert | update | delete |
|---|---|---|---|---|
| Dibi | 1617.242 | 134.966 | 428.421 | 249.887 |
| Doctrine 2 | 1390.539 | 457.234 | 755.267 | 403.661 |
| NotORM | 706.752 | 134.887 | 128.954 | 160.803 |
Paměťová náročnost (kB)
| Knihovna | select | insert | update | delete |
|---|---|---|---|---|
| Dibi | 6600.972 | 4920.087 | 4925.632 | 4877.281 |
| Doctrine 2 | 9439.350 | 7056.554 | 7102.958 | 7005.480 |
| NotORM | 10866.855 | 4174.809 | 4395.336 | 4144.314 |
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
- PHP 5.3.2 TS VC6
- Apache 2.2.15
- Windows XP
- MySQL 5.1.39-community
- Nette Framework 1.0-dev (revision a8c51dd)
- Athlon 64 X2.
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.
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.
Jakub Vrána 
:
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.
Jakub Vrána : 
Joelp:
Navíc graf nemá popsané osy, takže je tak či tak na nic. Že je to v tabulce nic neomlouvá.
Joelp: 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.
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.
Ondrej Mirtes: 
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).
Patrik Votoček: 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...
Jakub Vrána :
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.
Jakub Vrána : milan:
nejvíce mě zarazilo, že oproti původnímu testu jsou poměry dibi/doctrine naprosto odlišné. Jakub Vrána :
Asi ses špatně koukal, stejné křivky v grafech vypadají velmi podobně.
Jakub Vrána : 
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.
v6ak: Jakub Vrána :
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.
Jakub Vrána : 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.
v6ak: 
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.
David Grudl: v6ak:
Zajímavá poznámka. Ale řekl bych, že k NotORM je podobnější spíše DibiFluent.
v6ak: 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.phpDiskuse je zrušena z důvodu spamu.
© 2005-2024 