Propel vs Doctrine - wynik testu - może jakiś komentarz ? Opcje

[yankes]

wczoraj z okazji prac nad pewnym projektem i odwiecznego pytania: Doctrine vs Propel poszukałem i znalazłem

dla potomnych: http://code.google.com/p/php-orm-benchmark...unk/doctrine_12
prosty benchmark: PDO / Propel 1.4 / Propel 1.5 / Propel 1.5 ( with Cache ) / Doctrine 1.2 / Doctrine 2 / Doctrine 2 ( with Cache )

zanim zdecydujecie się samemu pogrzebać/testować pamiętajcie, że Doctrine 2 pracuje z php 5.3.2

oki.. wynik moich testów 'delikatnie' mnie zdziwił:

[PHP] pobierz, plaintext 
 
                                         | Insert | findPk|complex| hydrate|  with  |
                                          |--------|--------|--------|--------|--------|
 
PDOTestSuite                      |    153  |    154 |    110 |    116 |    103 |
 
Propel14TestSuite                |   1214 |    529 |    137 |    321 |    315 |
 
Propel15TestSuite                 |   1122 |    725 |    250 |    426 |    439 |
 
Propel15WithCacheTestSuite  |   1026 |    453 |    171 |    346 |    331 |
 
Doctrine12TestSuite              |   2168 |   3697 |    569 |   1990 |   2545 |
 
Doctrine2TestSuite                |    189 |    503 |    426 |   1408 |   1284 |
 
Doctrine2WithCacheTestSuite |    203 |    543 |    137 |    769 |    431 |
[PHP] pobierz, plaintext 

z tego wynika, że bardzo popularny obecnie Doctrine 1.2 to niezły 'żółw'.....
może ktoś doda coś od siebie na ten temat ? bo może ja coś przeoczyłem ...

Ten post edytował yankes 9.05.2010, 22:58:00

[xdev]

PDO pewnie ma "łatkę" wolnego bo gdyby puścić benchmark najprostszego api (mysql_*) to czasy byłyby prawdopodobnie jeszcze lepsze. Kiepskie wyniki ORM-ów wcale mnie nie dziwią. PHP do najszybszych języków nie należy, kod wypluwany przez ORM-y też z wydajnością ma niewiele wspólnego.

Z resztą żadna warstwa abstrakcji ani wirtualizacji jeszcze nigdy niczego nie przyspieszyła. Założenia przy tworzeniu takich systemów to nie wzrost prędkości.

Oczywiście macie rację, że czas programisty kosztuje dużo więcej niż nawet najlepszy sprzęt i gdyby kod był nawet 10 razy wolniejszy ale projekt można byłoby skończyć tydzień szybciej to by się pewnie w wielu przypadkach opłaciło. Jednak problem jest inny. SQL to świetny model, OOP do którego tłumaczy ORM jest strasznie "drewniane". Może wam się wydaje, że zaoszczędzicie trochę czasu na pisaniu prostych selectów po kluczu, ale szybko zrozumiecie, że kiedy trzeba zrobić coś bardziej skomplikowanego to SQL jest nie dość, że dużo prostsze to jeszcze bardzo elastyczne i łatwe w modyfikacji.

Lepiej bardzo dobrze poznać SQL niż uczyć się redundantnej technologii której jedynym plusem jest to, że chroni osoby całkowicie zielone przed SQL-Injection. Ściągnąć sobie jakieś dobre narzędzie do graficznego projektowania baz, żeby nie tracić czasu na klepanie w kółko tego samego. Zwłaszcza, że jeśli zaczniecie jakieś bardziej skomplikowane projekty to i tak się skończy na analizie czystego SQL-a i pisaniu kwerend z palca (macie 5 krotny spadek wydajności dla prostych selectów, dla bardziej skomplikowanych analiz danych zależnie od optymalizacji kwerendy mogą się wykonywać 2 dni albo 2 minuty).

Dla tabel poniżej 10-100k wierszy optymalizacja nie ma znaczenia, dlatego wydaje się, że ORM jest taki fajny... nawet nie taki wolny i tak się w nim szybko pisze projekty. Projekt się rozrośnie, będziecie brali ten garbage który wypluwa wasz ulubiuony ORM, wrzucali przed to EXPLAIN i klęli

http://en.wikipedia.org/wiki/Technical_debt
Design debt... szybciej stworzycie pierwszą wersję skryptu, ale za złą decyzję projektową jaką jest w większości wypadków użycia ORMa (jakiegokolwiek) będziecie "płacić" wolnym rozwojem projektu przez cały cykl życia kodu.