Patrik Votoček

weBlog



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
Grafické znázornění předchozí tabulky

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
Grafické znázornění předchozí tabulky

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
Grafické znázornění předchozí tabulky

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ů:

  1. Jaké je reálné využití 100 insertů do stejné tabulky v rámci jedné transakce? To už by bylo lepší zavolat jeden vícehodnotový INSERT.
  2. Test nijak nezohledňuje nastavení MySQL innodb_flush_log_­at_trx_commit, které bude mít na výsledek dramatický dopad.
  3. NotORM není náhradou nižší vrstvy (jako třeba Dibi), je jejím doplňkem. Takže zatímco Dibi přijímá přihlašovací údaje, NotORM přijímá objekt s připojením, který tím pádem mohu nadále normálně používat. Důsledek tohoto rozdílu je ten, že transakce mohu zcela přirozeně ovládat přímo na objektu s připojením.
  4. Do počtu dotazů UPDATE pro Doctrine 2 jsi započítal jen SELECTy (zapomněl jsi na metodu executeUpdate).

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.

Jakub Vrána avatar

Jan Tichý

nový

Jaké je reálné využití 100 insertů do stejné tabulky v rámci jedné transakce? To už by bylo lepší zavolat jeden vícehodnotový INSERT.

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.

Jan Tichý avatar

Patrik Votoček

nový

@Jakub:

  1. Jak už napsal honza tady nejde o to jak moc je to reálné ale že to ve skutečnosti nemusím řešit.
  2. Abych pravdu řekl tak o innodb_flush_log_at_trx_commit jsem do této chvíle nevěděl (jsem zase chytřejší)
  3. To je právě důvod proč jsem do prvního článku NotORM nezahrnul. Testoval jsem různá ORM řešení a pro srovnání jsem přidal dibi.
  4. zapoměl jsem pushnout změnu započítané by to být mělo.
Patrik Votoček avatar

Přidej komentář



Twitter

Small PHP IDE test (@NetBeans vs. PhpED) http://jdem.cz/g9225 #php #ide #test #5.3

cenzuruje váš poskytovatel připojení?
WebExpo 2010

Kategorie

Čtu

Kamarádi