Temat: ORM hamulcem wydajności?

http://bit.ly/qcqjlC

Jakie jest wasze zdanie na ten temat?

Temat: ORM hamulcem wydajności?

Zależy jaki co jest priorytetem. Jeśli wydajność i tylko wydajność to oczywistym jest, że ORM to zły pomysł. Ale jeśli wydajność jest gdzieś pod koniec listy to dlaczego nie ORM?

Poza tym jest jeszcze sprawa kosztów. Bez precyzyjnej analizy ile będzie kosztował maintenance z bez ORM a ile z ORM (ale za to z kosztem mocniejszych serwerów) taka dyskusja jest czysto akademicka - taka sztuka dla sztuki. A bez wiedzy o jakim projekcie mówimy taka analiza jest niemożliwa.

Gdyby wydajność była zawsze jedynym kryterium to trzeba by wszystko pisać w języku maszynowym. Wtedy to dopiero było by wydajne ;) Tylko jakoś nikt tak nie robi... Ciekawe dlaczego ;) Jak by się uprzeć to może powiedzieć, że wszystko powyżej assemblera jest hamulcem wydajności :)

Edit: Było "bez ORM (ale za to z kosztem mocniejszych serwerów) - troszkę mi się popierniczyło ;)Aleksander Wons edytował(a) ten post dnia 24.09.11 o godzinie 21:22

Temat: ORM hamulcem wydajności?

Kryterium dla mnie to był zawsze czas. Jeżeli wydajność nie była ważna (aplikacja/strona nie będzie działać pod dużym obciążeniem) to stosuje ORM.
Łatwy w obsłudze, szybki do zaimplementowania.
W innym wypadku polegam na własnych rozwiązaniach. Zresztą do nowych projektów już raczej stosuje własne które są napisane pod moje "widzi mi się" i przy okazji są robione w trosce o wydajność.

Temat: ORM hamulcem wydajności?

Aleksander Wons:

Gdyby wydajność była zawsze jedynym kryterium to trzeba by wszystko pisać w języku maszynowym. Wtedy to dopiero było by wydajne ;) [...]

To juz dawno nie jest stwierdzenie prawdziwe. Wspolczesne kompilatory C++ optymalizuja kod daleko skuteczniej niz czlowiek/programista asma.

Nawet zaryzykowalbym ze C# tez tak ma...

A ORMy? nie wydaje mi sie zeby az tak bardzo wplywaly na wydajnosc w typowych zastosowaniach. W tych mniej typowych, NH, pozwala uzyc SQL-a i oferowac wciaz mappery do obiektow.

Za to na pewno ORMy pozwalaja uniknac wielu bezsensownych pomylek --> sytuacja chyba moze byc przyrownana do kompilatorow vs asm.

A ze kazda architekture mozna sp.... to nie powod do wieszania psow na ORMy.

Temat: ORM hamulcem wydajności?

Roland Żerek:

Aleksander Wons:
Gdyby wydajność była zawsze jedynym kryterium to trzeba by wszystko pisać w języku maszynowym. Wtedy to dopiero było by wydajne ;) [...]

To juz dawno nie jest stwierdzenie prawdziwe. Wspolczesne kompilatory C++ optymalizuja kod daleko skuteczniej niz czlowiek/programista asma.

Nawet zaryzykowalbym ze C# tez tak ma...

Mnie się jednak wydaje, że spec od ASM napisze coś wydajniejszego niż to samo skompilowane z C++/C# - bez względu na to, jak wydajny jest kompiler. A to, że różnice pewnie będą marinalne... to już inny bajka :) Patrząc na każdy projekt tylko z perspektywy wydajności do dzisiaj nie było by niczego innego poza językiem maszynowym.

Użycia tej czy innej technologi, bazy danych, ORM-a lub nie ORM-a jest determinowane przez wymagania projektu (ewentualnie zasobność portfela i ramy czasowe). Takie uogólnienia jak w przytoczonym artykule są brzydko mówiąc o dupe rozbić :)

Temat: ORM hamulcem wydajności?

Kto rozsądny ten wie, że nie ma sensu optymalizować całego programu, bo zysk jest znikomy w porównaniu do kosztów. Błyskawicznie kodujemy sobie z ORMem u boku, potem profilujemy i patrzymy gdzie prawdziwe problemy się dzieją i tam punktowo jakiegoś małego cache'a wpinamy, albo generowane joiny zastępujemy ręcznym, efektywniejszym. Nie ma co generalizować, jak to kolega przede mną rzekł

Temat: ORM hamulcem wydajności?

Aleksander Wons:

Roland Żerek:

Aleksander Wons:
Gdyby wydajność była zawsze jedynym kryterium to trzeba by wszystko pisać w języku maszynowym. Wtedy to dopiero było by wydajne ;) [...]

To juz dawno nie jest stwierdzenie prawdziwe. Wspolczesne kompilatory C++ optymalizuja kod daleko skuteczniej niz czlowiek/programista asma.

Nawet zaryzykowalbym ze C# tez tak ma...

Mnie się jednak wydaje, że spec od ASM napisze coś wydajniejszego niż to samo skompilowane z C++/C# - bez względu na to, jak wydajny jest kompiler.

Nie zgodzę się. Dzisiejsze kompilatory to efekt dziesięcioleci doświadczeń i badań na prawdę tęgich umysłów. Podejrzewam, że uwzględniają wiele scenariuszy optymalizacyjnych.

Do nas, programistów, należy jedynie optymalizacja algorytmów, a nie zabawa w przestawianie instrukcji, bo w potoku tak będzie lepiej... Na jednej architekturze będzie, a na innej wydajność się załamie...

Użycia tej czy innej technologi, bazy danych, ORM-a lub nie ORM-a jest determinowane przez wymagania projektu (ewentualnie zasobność portfela i ramy czasowe). Takie uogólnienia jak w przytoczonym artykule są brzydko mówiąc o dupe rozbić :)

Otóż to. I dodam, że jednak użycie ORM-a w wielu przypadkach będzie jednak korzystne i rezygnowanie z niego to strata dla projektu.

Temat: ORM hamulcem wydajności?

Roland Żerek:

Nie zgodzę się. Dzisiejsze kompilatory to efekt dziesięcioleci doświadczeń i badań na prawdę tęgich umysłów. Podejrzewam, że uwzględniają wiele scenariuszy optymalizacyjnych.

Tak na prawdę można by to sprawdzić tylko porównując dwa sporych rozmiarów systemy robiące dokładnie to samo. Jeden pisany na przykład w C++ a drugi w ASM. Ale przecież nikt o zdrowych zmysłach tego nie zrobi, bo jak wiadomo nie o to w tym wszystkim chodzi :)

Do nas, programistów, należy jedynie optymalizacja algorytmów, a nie zabawa w przestawianie instrukcji, bo w potoku tak będzie lepiej... Na jednej architekturze będzie, a na innej wydajność się załamie...

Dokładnie. A dodtkowo istotny jest wybór narzędzi w zależności od prjektu, zasobności portfela klienta i posiadanego czasu na realizację.

Otóż to. I dodam, że jednak użycie ORM-a w wielu przypadkach będzie jednak korzystne i rezygnowanie z niego to strata dla projektu.

Osobiście przerobiłem już takich projektów sporo. Każdy na tyle mały (w sensie obciążenia procesora i bazy) że nie zastosowanie ORM-a było by wyłącznie sptratą czasu i pieniędzy. Niczym więcej.

A bybły też i takie gdzie użytkowników to może było i dwóch ale za to ORM nadawał się tak to 10% systemu. Reszta to czyste zapytania, triggery, procedury składowe i funkcje.

Temat: ORM hamulcem wydajności?

Oczywiście nie ma sensu optymalizować całego systemu i porównanie C++/ASM do ORM/SQL jest moim zdaniem też trafne.

Tylko że nadal (gry, hpc, chociaż coraz rzadziej) łączy się C++ z ASM (i np. Pythona z C).

A czy każdy ORM można ominąć? Jeśli nie to z którymi bywają problemy?

Temat: ORM hamulcem wydajności?

Co to znaczy "ominąć"? ORM to nie jest integralna część oprogramowania. Tym bardziej nie autorskiego. Chesz to używasz. Nie chce to nie.

Temat: ORM hamulcem wydajności?

Piotr L.:
http://bit.ly/qcqjlC

Jakie jest wasze zdanie na ten temat?

IMO duzo ciekawiej napisal ten czlowiek:
http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern

Aleksander Wons:
Zależy jaki co jest priorytetem. Jeśli wydajność i tylko wydajność to oczywistym jest, że ORM to zły pomysł. Ale jeśli wydajność jest gdzieś pod koniec listy to dlaczego nie ORM?

Moim zdaniem bledem jest mowienie o ORM, bo to koncepcja. Jej implementacje moga roznic reprezentowac dwa przeciwlegle bieguny wydajnosci, patrz: Entity Framework i NHibernate.

Poza tym jest jeszcze sprawa kosztów. Bez precyzyjnej analizy ile będzie kosztował maintenance z bez ORM a ile z ORM (ale za to z kosztem mocniejszych serwerów) taka dyskusja jest czysto akademicka - taka sztuka dla sztuki. A bez wiedzy o jakim projekcie mówimy taka analiza jest niemożliwa.

W rzeczywistosci procedury skladowane pisane sa pod katem danej operacji czastkowej, wykonuja konkretna funkcje i koncza swoje dzialanie. Im bardziej zlozony jest system, tym wiecej operacji wykonywanych jest pod rzad. W przypadku problemow wydajnosciowych optymalizuje sie cala serie tych operacji, co prowadzi do gwaltownego wzrostu ilosci procedur skladowanych. Trzeba je pisac pod katem konkretnych sciezek (logiki) wykonania programu.

Dla przykladu w NHibernate tego rodzaju operacje mozemy skolejkowac po stronie aplikacji i wyslac je w jednym batchu. Rowniez wiekszosc selectow mozemy zoptymalizowac (projection) pod katem danej decyzji biznesowej. Np. jezeli dla danego statusu okreslone count'y nie sa potrzebne mozemy je bardzo latwo pominac przy wywolaniu LINQ .Select. W procedurach skladowanych skonczyloby sie albo na dynamicznym SQL, albo na 2 procedurach jednej omijajacej selecty.

W praktyce w pewnym momencie musisz powiedziec "stop" przy optymalizacji procedur, tego ograniczenia nie masz w tworzeniu kolejki zapytan na IQueryable. Dodatkowo utrzymanie SP, ktore predzej czy pozniej zaczynaja zawierac coraz wiecej logiki aplikacji jest coraz wieksza bolaczka i nie lada wyzwaniem.

Tworzac standardowe abstrakcje (Active Record, Domain Factory) mozesz bardzo latwo przeskakiwac z ORM/SQL/SP bez wiekszego wplywu na dzialanie aplikacji. Trzeba zawsze pamietac, ze ORM nie zwalnia Cie z obowiazku myslenia o wydajnosci, ale daje sprawne narzedzie do myslenia o niej w kontekscie operacji biznesowej. To bardzo mocna, czesto decyzyjna cecha dla wydajnosci systemu.

Z wlasnej praktyki moge powiedziec, ze umiejetnie napisana aplikacja korzystajaca z NHibernate dziala zauwazalnie szybciej niz umiejetnie napisana aplikacja na Stored Procedures. Fakt faktem, ze w naszym wypadku do 500MB/dzien roznice nie byly zauwazalne, ale powyzej tej granicy procedury przestaly sobie radzic. NHibernate testowalismy przy 2GB/dzien i zauwazylismy spory zapas mocy przy pracy na identycznym serwerze. Uwazam, ze nie ma odpowiedzi na pytanie co jest szybsze, bo to mocno zalezy.

Zawsze znajda sie programisci, ktorzy beda chwalic pod niebiosa MS Access, zawsze znajda sie purysci pracujacy z aplikacjami webowymi w C++ i oczywiscie zawsze znajdzie sie ktos, kto uzasadni swoje stanowisko pracy (+ zakup serwerow za setki tysiecy funtow) tym, ze ORM jest "be" i "SP is the way to go".

Temat: ORM hamulcem wydajności?

Sebastian Pienio:

Piotr L.:
http://bit.ly/qcqjlC

Jakie jest wasze zdanie na ten temat?

IMO duzo ciekawiej napisal ten czlowiek:
http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern

Końcówka to jest właśnie to do czego doszedłem po kilku projektach.
Dobry artykuł, dzięki!

Temat: ORM hamulcem wydajności?

Ok, to proszę przykład obsługi userów w aplikacji OO z backendem w RDBMS. Bez ORM. Jak wydobywamy i obsługujemy dane o userze/usera.Łukasz K. edytował(a) ten post dnia 03.10.11 o godzinie 00:00

Temat: ORM hamulcem wydajności?

Łukasz K.:
Ok, to proszę przykład obsługi userów w aplikacji OO z backendem w RDBMS. Bez ORM. Jak wydobywamy i obsługujemy dane o userze/usera.

To chyba zbyt prosty przykład żeby rezygnować z ORM.

Ale gdyby pozostać przy użytkownikach, czy da się zrobić w ORM (dajmy na to w Propel) coś takiego jak poniżej? (oczywiście bez SQL-a).

"podaj listę 5 najbardziej aktywnych użytkowników grupy, posortuj wg daty pierwszego wpisu w grupie"

Takie zestawienia lub podobne nie są wbrew pozorom czymś super wymyślnym.

Ktoś napisał ciekawe stwierdzenie:
"Although it may seem trite to say it, (ORM) is the Vietnam of Computer Science. It represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy."

Temat: ORM hamulcem wydajności?

Piotr L.:

Łukasz K.:
Ok, to proszę przykład obsługi userów w aplikacji OO z backendem w RDBMS. Bez ORM. Jak wydobywamy i obsługujemy dane o userze/usera.

To chyba zbyt prosty przykład żeby rezygnować z ORM.

Zaraz, zaraz. To ORM są do rozwiązywania prostych problemów? Trudniejsze tego nie wymagają? Hmmmm... (No dobra, wiem o co chodzi ;))

Ale gdyby pozostać przy użytkownikach, czy da się zrobić w ORM (dajmy na to w Propel) coś takiego jak poniżej? (oczywiście bez SQL-a).

"podaj listę 5 najbardziej aktywnych użytkowników grupy, posortuj wg daty pierwszego wpisu w grupie"

To nie jest mapowanie. Da się natomiast za pomocą zapytania wybrać ID userów, a ORM ubierze ich w obiekty.

Takie zestawienia lub podobne nie są wbrew pozorom czymś super wymyślnym.

Pewnie nie. Tylko rolą mapowacza jest mapowanie, a nie robienie zestawień. Jeśli natomiast ORM łamie zasadę pojedynczej odpowiedzialności, do tego robiąc to nieudolnie, to już problem konkretnego ORM-a, nie wzorca.Łukasz K. edytował(a) ten post dnia 03.10.11 o godzinie 13:39

Temat: ORM hamulcem wydajności?

Piotr L.:
Ale gdyby pozostać przy użytkownikach, czy da się zrobić w ORM (dajmy na to w Propel) coś takiego jak poniżej? (oczywiście bez SQL-a).

"podaj listę 5 najbardziej aktywnych użytkowników grupy, posortuj wg daty pierwszego wpisu w grupie"

W LINQ to by lecialo jakos tak:

var usersInGroup = group.Users;

var activeUsers = usersInGroup

 .OrderByDescending(x => x.Posts.Count())

 .Take(5)

 .OrderByDescending(x => x.Posts.Min(post => post.Created))

 .Select(x => x.ID, x.Name, x.Posts.Count())

 .ToList();

Przy okazji w przykladzie pokazalem jak wyciagnac jedynie ID, nazwe i ilosc postow uzytkownika.

Takie zestawienia lub podobne nie są wbrew pozorom czymś super wymyślnym.

Ktoś napisał ciekawe stwierdzenie:
"Although it may seem trite to say it, (ORM) is the Vietnam of Computer Science. It represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy."

W wielu punktach nie zgadzam sie z autorem publikacji i uwazam, ze ORM jako koncepcja nie jest anti-patternem. Fakt, ze mozna taka teze udowodnic dla niektorych implementacji ORM.

Temat: ORM hamulcem wydajności?

Sebastian Pienio:
Przy okazji w przykladzie pokazalem jak wyciagnac jedynie ID, nazwe i ilosc postow uzytkownika.

Takie zestawienia lub podobne nie są wbrew pozorom czymś super wymyślnym.

Ktoś napisał ciekawe stwierdzenie:
"Although it may seem trite to say it, (ORM) is the Vietnam of Computer Science. It represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy."

W wielu punktach nie zgadzam sie z autorem publikacji i uwazam, ze ORM jako koncepcja nie jest anti-patternem. Fakt, ze mozna taka teze udowodnic dla niektorych implementacji ORM.

No właśnie chętnie dowiedziałbym się na które ORM-y uważać.
Które można uznać za takie "ślepe uliczki"? I dlaczego?

Temat: ORM hamulcem wydajności?

Drugi artykuł całkiem ciekawy, ale jego autor chyba nie do końca rozumie to o czym pisze.

1. "Unfortunately, these advantages disappear as the project increases in complexity: the abstraction breaks down, forcing the dev to use and understand SQL".
Od kiedy to modelem i bazą zajmuje się ktoś kto nie ma pojęcia o SQL? Jeśli autor tego posta właśnie tak robi... To nie dziwi mnie, że jak projekt się rozrasta to się robi problem. ORM ma ułatwić pewne zadania, ale to rola developera żeby ustalić jakie się da zastapić ORM-em a jakich nie. Kiedy użycie ORM-owego generatora zapytań ma sens a kiedy trzeba samemu napisać zapytanie. Kiedy hydrować wyniki do obiektów a keidy pracować na raw data.

2. "On the the other hand, if your data is relational, then your object mapping will eventually break down".
Ciekawe stwierdzenie. Pal licho, że autor na popacie tej tezy nie przedstawił ani jednego argumentu (ten z obiektami X, Y i Z to raczej nieudolna próba udowodnienia kompletnie nielogicznej tezy).
Od kiedo to mapowane dane muszą ZAWSZE odwzorowywać wszystkie możliwe relacje? Co to za ciekawa teza? Czyli jak potrzebuje wyciągnąć pojedyńczego SMS-a to musze go zawsze łączyć z operatorem, krajem, bulkami w których się pojawiał, użytkownikami, którzy wysyłali coś na ten numer, ich uprawnieniami, fakturami itd itp? Szkoda, że autor nie uzasadnił czemu to ma służyć. Zapewne jest to jakaś głębsza idea, której nie rozumiem.

Z każdym ORM-em najlepiej zapoznać się przez przeczytanie dokładnie dokumentacji. Wtedy czarno na białym widać co możemy z niego wykrzesać a czego nie. Nie ma tu raczej uniwersalnej zasady. Osobiście miałem okazję używać wszystkich wersji Propela i Doctrine. Każdy ma swoje wady i zalety. I bardzo częśto używam ORM-a tylko do pobrania odpowiedniego połączenia do bazy. A SQL-la i tak piszę z palca bo nie ma sensu stosowanie ORM-a do tego. Ale to już trzeba ocenić samemu na podstawie tego co mamy do zrobienia.

Temat: ORM hamulcem wydajności?

Się zduplikowało.Aleksander Wons edytował(a) ten post dnia 03.10.11 o godzinie 15:08