Propel vs Doctrine - wynik testu - może jakiś komentarz ? |
Propel vs Doctrine - wynik testu - może jakiś komentarz ? |
9.05.2010, 20:36:10
Post
#1
|
|
Grupa: Zarejestrowani Postów: 41 Pomógł: 1 Dołączył: 13.01.2006 Ostrzeżenie: (0%) |
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ł:
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 |
|
|
17.05.2010, 18:14:43
Post
#2
|
|
Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) |
A może byś tak jeszcze napisał, co oznaczają te cyferki, jak uruchamiałeś, ogólnie metodologię? Takie pseudobenchmarki z cyferkami i bez słowa komentarza to o kant czterech liter można rozbić.
Natomiast Doctrine 1.x demonem szybkości nie jest i to nie jest żadna tajemnica, zwłaszcza jak robisz hydrację wyników do obiektów zamiast do tablic. -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
18.05.2010, 08:03:33
Post
#3
|
|
Grupa: Zarejestrowani Postów: 41 Pomógł: 1 Dołączył: 13.01.2006 Ostrzeżenie: (0%) |
Zyx: specjalnie, żeby nie było pytań o metodologię i na użytek innych dałem link do skryptu, którym testowałem.
Jest to czas w mikrosekundach jaki dany ORM potrzebował na wykonanie zapytania. Tu masz główną klasę abstract:
a tu klase od Doctrine 1.2, która dziedziczy z tej abstrakcyjnej:
|
|
|
18.05.2010, 16:33:09
Post
#4
|
|
Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) |
Widzę, że dałeś. Sęk w tym, że nie wszyscy mają czas, by to ściągać, uruchamiać i rozkminiać wszystko metodą inżynierii wstecznej tylko po to, by się dowiedzieć, że wyniki są w mikrosekundach, bo autor benchmarka umarłby z wysiłku, gdyby o tym wspomniał. Ponadto sam kod nie mówi nic o tym czy np. testy uruchamiałeś kilkakrotnie, czy i jak uśredniałeś wyniki, czyli o wszystkich tych rzeczach związanych z późniejszą obróbką.
Powtarzam: Cytat Doctrine 1.x demonem szybkości nie jest i to nie jest żadna tajemnica, zwłaszcza jak robisz hydrację wyników do obiektów zamiast do tablic.
Ten post edytował Zyx 18.05.2010, 16:33:43 -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
18.05.2010, 21:41:25
Post
#5
|
|
Grupa: Zarejestrowani Postów: 41 Pomógł: 1 Dołączył: 13.01.2006 Ostrzeżenie: (0%) |
Zyx: testy były uruchamiane min 10 razy na 3 różnych maszynach, wynik ciągle przybliżony. A co do Doctrine 1.2 to jest 'załamany' jego wydajnością. I poważnie zastanawiam się co dalej.. Wybiorę Propel to niedługo ( albo i już ) będzie dodatkowym pluginem do Symfony. Głównym jest doctrine 1.2 a potem ma być doctrine 2. Z tego co widzę to coraz więcej pluginów jest robionych pod Doctrine ;/ ciężki wybór
|
|
|
18.05.2010, 23:01:45
Post
#6
|
|
Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) |
W porządku, to może jeszcze byś odpowiedział na wątpliwość, którą już trzeci raz powtórzę:
Cytat zwłaszcza jak robisz hydrację wyników do obiektów zamiast do tablic. Dlaczego używasz hydracji do obiektów we wszystkich testach, skoro sami autorzy piszą w dokumentacji, że jest ona dość wolna i aby nie używać jej, jeśli nie chcemy później wykonywać modyfikacji danych za pomocą tych obiektów. -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
19.05.2010, 09:18:53
Post
#7
|
|
Grupa: Zarejestrowani Postów: 41 Pomógł: 1 Dołączył: 13.01.2006 Ostrzeżenie: (0%) |
Zyx: wiem, że hydrację wyników do obiektów zamiast do tablic jest wolniejsza, dziś zrobie te same testy z hydracją do tablic przy insert i szukaniu po PK.
Jeżeli możesz podziel się linkiem do dokumenacji gdzie jest mowa o: "skoro sami autorzy piszą w dokumentacji, że jest ona dość wolna i aby nie używać jej". |
|
|
19.05.2010, 09:43:28
Post
#8
|
|
Grupa: Zarejestrowani Postów: 23 Pomógł: 2 Dołączył: 17.06.2004 Ostrzeżenie: (0%) |
Jeżeli możesz podziel się linkiem do dokumenacji gdzie jest mowa o: "skoro sami autorzy piszą w dokumentacji, że jest ona dość wolna i aby nie używać jej". Zyx'owi chodziło chyba o to. -------------------- [workstation] PHPStorm, Apache 2/nginx, php 5.3/5.4, MySQL 5.5/5.6
[employers] Infor S.A., Gadu-Gadu S.A., Redefine, HBM, KnpLabs |
|
|
10.06.2010, 19:47:34
Post
#9
|
|
Grupa: Zarejestrowani Postów: 41 Pomógł: 1 Dołączył: 13.01.2006 Ostrzeżenie: (0%) |
oki chyba tak .. bo tylko to znalazłem na stronie Doctrine. Dziś nowe testy ;] zobaczymy jak wyjdzie.
Wracam do zapomnianego wątku w przykładach było wyraźnie zaznaczone, że nie liczony jest czas hydracji :
ale pomimo tego postanowiłem zrobić dodatkową klasę z hydracją do tablic ( dla doctrine 1.2 ) wynik testów: Doctrine12TestSuiteARRAY - hydracja przeprowadzona dla wariantu: hydrate i with... rezultat... krzyż na drogę Doctrine poczekam sobie spokojnie na dopracowane Symfony 2 + Doctrine 2 ale to pewnie jakiś rok czasu |
|
|
15.06.2010, 14:31:24
Post
#10
|
|
Grupa: Zarejestrowani Postów: 53 Pomógł: 5 Dołączył: 13.04.2007 Skąd: Szczecin Ostrzeżenie: (0%) |
ale pomimo tego postanowiłem zrobić dodatkową klasę z hydracją do tablic ( dla doctrine 1.2 ) wynik testów: Doctrine12TestSuiteARRAY - hydracja przeprowadzona dla wariantu: hydrate i with... rezultat... krzyż na drogę Doctrine poczekam sobie spokojnie na dopracowane Symfony 2 + Doctrine 2 ale to pewnie jakiś rok czasu ja nie wiem jak to testujesz bo na svenie nie ma klasy z hydracja do tablic (1.2) ale z mojego szybkiego testu wynika ze jest ona conajmniej 2x szybsza na prostym findAll ze zlaczeniami.
powiedz jeszcze po kiego ten foreach? caly ten twoj test i wnioski sa.. hm, slabe Ten post edytował murwazy 15.06.2010, 14:32:21 |
|
|
15.06.2010, 20:34:12
Post
#11
|
|
Grupa: Zarejestrowani Postów: 41 Pomógł: 1 Dołączył: 13.01.2006 Ostrzeżenie: (0%) |
słaby to jest Doctrine i myślenie niektórych o nowościach promowanych przez Fabiena:
kawałek kodu którego użyłem to pomiary z hydracją:
jak na moje foreach jest wyraźnie zakomentowany - a po co tam jest ? zapytaj autora skryptu, który pobierasz z SVN druga sprawa to czemu upieracie się żeby testować Propel ( defaultowe ustawienia - hydracja obiekt ) vs Doctrine ( hydracja do tablic ) ? aaa i nie jest to mój test... ;] tylko ROZWAŻANIA na podstawie gotowego skryptu Cytat ja nie wiem jak to testujesz bo na svenie nie ma klasy z hydracja do tablic (1.2) zauważ, że w teście pojawiła się klasa: Doctrine12TestSuiteARRAY - której to nie ma na tym SVN-ie Ten post edytował yankes 15.06.2010, 20:36:51 |
|
|
15.06.2010, 22:02:06
Post
#12
|
|
Grupa: Zarejestrowani Postów: 53 Pomógł: 5 Dołączył: 13.04.2007 Skąd: Szczecin Ostrzeżenie: (0%) |
słaby to jest Doctrine i myślenie niektórych o nowościach promowanych przez Fabiena: kawałek kodu którego użyłem to pomiary z hydracją:
jak na moje foreach jest wyraźnie zakomentowany - a po co tam jest ? zapytaj autora skryptu, który pobierasz z SVN kawalek kodu z hydracja do obiektu a nie do tablicy, w tym rzecz. wczesniej nie podales kodu, ktory testowales, skad mam wiedziec czy tym razem wykomentowales druga sprawa to czemu upieracie się żeby testować Propel ( defaultowe ustawienia - hydracja obiekt ) vs Doctrine ( hydracja do tablic ) ? skoro doctrine ma taki ficzer to dlaczego go nie uzywac? zwlaszcza jesli jest to szybsze rozwiazanie. po co na sile promowac propela? imho liczy sie czas wykonania zadania, skoro doctrine ma tu przewage (hydracja do tablic) to dlaczego jej nie uzywac? propel byc moze jest szybszy we wbijaniu gwozdzi ale doctrine ma metode wiertarka aaa i nie jest to mój test... ;] tylko ROZWAŻANIA na podstawie gotowego skryptu przyjalem do wiadomosci zauważ, że w teście pojawiła się klasa: Doctrine12TestSuiteARRAY - której to nie ma na tym SVN-ie owszem, ale nie podales zrodel do ostatniego testu pozdrawiam Ten post edytował murwazy 15.06.2010, 22:02:38 |
|
|
16.06.2010, 19:33:38
Post
#13
|
|
Grupa: Zarejestrowani Postów: 4 655 Pomógł: 556 Dołączył: 17.03.2009 Skąd: Katowice Ostrzeżenie: (0%) |
Wyniki powiem, że mnie bardzo zadziwiły - myślałem, że PDO będzie na samym końcu, a tutaj niespodzianka, najszybszy, konkurencja bez szans - no ale jednak, co stworzone przez twórców języka, chodzi troszkę lepiej. ;p
-------------------- Zainteresowania: C#, PHP, JS, SQL, AJAX, XML, C dla AVR
Chętnie pomogę, lecz zanim napiszesz: Wujek Google , Manual PHP |
|
|
16.06.2010, 20:22:00
Post
#14
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
@fifi209: Może dlatego, że PDO nie jest ORMem?
|
|
|
16.06.2010, 21:30:49
Post
#15
|
|
Grupa: Zarejestrowani Postów: 4 655 Pomógł: 556 Dołączył: 17.03.2009 Skąd: Katowice Ostrzeżenie: (0%) |
@fifi209: Może dlatego, że PDO nie jest ORMem? Miałem na myśli samo zaskoczenie jak wypada PDO - większość ludzi mówi, że jest takie wolne itd. -------------------- Zainteresowania: C#, PHP, JS, SQL, AJAX, XML, C dla AVR
Chętnie pomogę, lecz zanim napiszesz: Wujek Google , Manual PHP |
|
|
16.06.2010, 23:05:06
Post
#16
|
|
Grupa: Zarejestrowani Postów: 114 Pomógł: 24 Dołączył: 18.01.2008 Skąd: Warszawa Ostrzeżenie: (0%) |
Cytat myślałem, że PDO będzie na samym końcu, a tutaj niespodzianka, najszybszy, konkurencja bez szans - no ale jednak, co stworzone przez twórców języka, chodzi troszkę lepiej. ;p http://github.com/doctrine/doctrine1/blob/.../Connection.php http://svn.propelorm.org/tags/1.5.1/runtim...n/PropelPDO.php taa... Cytat Doctrine 1.2 to niezły 'żółw' fakt, metody magiczne robią swoje Cytat ciężki wybór czemu wybierasz ORM ze względu na wydajność? 1. W większości przypadków optymalizacja jest nieopłacalna, dokupienie sprzętu jest tańsze niż czas pracy programisty 2. Jeżeli projekt okaże się niespodziewanym sukcesem i okaże się że warto go optymalizować to wtedy bawisz się w cache'owanie wszystkie co się da 3. Jeżeli w projekcie wydajność jest kluczowa to zrezygnuj z ORM'a Cytat słaby to jest Doctrine najwidoczniej jeszcze słabo znasz propela -------------------- |
|
|
17.09.2011, 20:26:47
Post
#17
|
|
Grupa: Zarejestrowani Postów: 39 Pomógł: 3 Dołączył: 17.09.2011 Ostrzeżenie: (0%) |
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. |
|
|
21.04.2015, 10:08:21
Post
#18
|
|
Grupa: Zarejestrowani Postów: 2 Pomógł: 0 Dołączył: 16.12.2014 Skąd: Warszawa Ostrzeżenie: (0%) |
Czy może ktoś porównywał najnowsze wersje Propela i Doctrine - czyli dwójki? Jestem na etapie decyzji, który ORM wybrać - Doctrine2 czy Propel 2, ale dosłownie nigdzie w sieci nie ma żadnych testów i ocen. Są tylko wpisy na temat starych wersji. Znalazłem artykuł Side by side: Doctrine2 and Propel 2, ale on zawiera porównanie cech i funkcjonalności. Wiem, że to też jest bardzo ważne, ale chciałbym, żeby ktoś mi wyraźnie napisał, którego ORM użyć (czyli który ORM jest lepszy jego zdaniem) i dlaczego. Ktoś pomoże?
|
|
|
Wersja Lo-Fi | Aktualny czas: 1.11.2024 - 00:13 |