ORM v číslech podruhé
V sobotu jsem vydal článek ve, kterém srovnávám různé ORM vrstvy používané ve spojení s Nette Frameworkem. Ve srovnání se nenacházelo NotORM od Jakuba Vrány . Jakub dnes do testu doplnil NotORM a požádal mě o změření za stejných podmínek jako ostatní měřená ORM v předchozím článku.
Nicméně já jsem hned po uveřejnění prvního článku věděl, že chci vydat další, který bude tentokráte laborovat nad výsledky optimalizovanějších verzí. Předchozí test byl totiž záměrně psán celkem hloupě. Optimalizace se týká „magického“ flush což není nic jiného než commitnutí transakce (proto je u testu s dibi využita klasicky). Nicméně dvě řešení v testu nemají nativní implementaci transakcí a na výsledcích je to znát. Umělé doplnění transakcí jsem totiž záměrně nedělal, protože né každý kdo má v plánu tyto ORM používat by si implementaci dopisoval sám. Ale teď už k výsledkům.
Srovnání
Čas (ms)
| ORM | Select | Insert | Update | Delete |
|---|---|---|---|---|
| dibi | 2791.19 | 221.61 | 317.83 | 192.29 |
| Ormion | 4288.53 | 2040.84 | 2413.9 | 2175.99 |
| ActiveMapper | 4607.46 | 503.44 | 768.47 | 350.66 |
| Doctrine 2 | 1729.24 | 275.01 | 334.06 | 265.47 |
| NotORM | 1523.02 | 2038.43 | 1928.26 | 2082.02 |

Paměť (kB)
| ORM | Select | Insert | Update | Delete |
|---|---|---|---|---|
| dibi | 7904.34 | 6223.72 | 6229.43 | 6178.07 |
| Ormion | 11778.8 | 6838.33 | 6841.07 | 6667.14 |
| ActiveMapper | 9368.03 | 7130.74 | 7279.26 | 7122.77 |
| Doctrine 2 | 11253.26 | 8797.25 | 8850.63 | 8725.25 |
| NotORM | 11945.85 | 5326.24 | 5545.17 | 5292.08 |

Dotazy (počet)
| ORM | Select | Insert | Update | Delete |
|---|---|---|---|---|
| dibi | 2000 | 100 | 150 | 100 |
| Ormion | 2000 | 100 | 150 | 100 |
| ActiveMapper | 1428 | 100 | 197 | 100 |
| Doctrine 2 | 1423 | 100 | 100 | 100 |
| NotORM | 2000 | 100 | 150 | 100 |

Jak je patrné až tady se ukazuje ohromná síla, kterou některá řešení disponují. Je celkem škoda že test se nezaměřuje na select bloku dat z databáze trochu jinak protože tam by NotORM hodně „drtilo“ konkurenci. Vzhledem k faktu, že jako jediné z testovaných řešení disponuje tzv. „předvídáním budoucnosti“.
Kódy jsou opět ve stejném repozitáři na GitHubu .

4 komentáře
Jakub Vrána
nový
Zatímco první test byl slušný syntetický benchmark, tenhle podle mě moc průkazný není z několika důvodů:
Pokud bys chtěl udělat test, který by lépe odpovídal realitě, tak by bylo lepší otestovat jednotlivé požadavky samostatně – tedy v každém requestu by byl pouze jeden dotaz a testovalo by se tisíc těchto requestů. Na to by zase mělo velký vliv zapnutí nebo vypnutí PHP akcelerátoru, takže by to chtělo dvoje výsledky.
Jan Tichý
nový
A to právě není pravda, respektive tohle já jako vývojář pracující na vyšší vrstvě vůbec nechci řešit.
To, jestli se to nakonec pošle jako sto insertů jebo jeden multiinsert, by za mě mělo vyřešit ORM.
Já si chci jenom založit sto entit a říct svému ORM, ať mi je persistuje. Jak si to ta ORM vrstva zkousne, to je její problém. Nechci ale řešit, jestli mám ty entity zakládat tak nebo onak, to není můj problém.
Patrik Votoček
nový
@Jakub:
innodb_flush_log_at_trx_commitjsem do této chvíle nevěděl (jsem zase chytřejší)Jakub Vrána
nový
4. Ať koukám, jak koukám, tak tam nic takového nevidím