Rychlost OO PHP

Objekt je nejsložitější datový typ a bude vždy nejpomalejší, už z principu struktury neustálého fčního volání. Žere také ohromné množství paměti. Pro rychlost se OOP určitě nepoužívá. BTW 500 objektů najednou mi připadá opravdu dost. Např. jedna stránka v nette má podle profileru inicializovaných kolem stovky objektů. Když se objektový model navrhne nešťastně tak to dokáže být -opravdu- pomalé, myslím tím hlavně OOP bez promyšleného použití návrhových vzorů apod..
OOP je mocný sluha, zlý pán ;)

No určitě se není potřeba bát použití objektů kvůli tomu, že by byly neúnosně pomalé. Na druhou stranu ale 500 objektů na stránku v PHP je opravdu hodně, také si nejsem jistý, jestli je to dobře navržené.

Lamicz:
Pokud například budeš dělat e-shop, tak co položka, to jeden formulář - tzn. kolik položek na stránce, tolik instancí třídy AppForm. Takžé tvé číslo jednoduše naroste. Ale nikde tam nevidím počet objektů, ale počet tříd. Za objekt se přece považuje instance nějaké třídy, ne?

joe:
Ano je to tak objekt == instance.

500 je sice trochu vic ale az tak nemozne to neni (jinak dane reseni by se mohlo resit uplne jinak nez pomoci OOP).

Zase ale kdyz uz php tak oop, proceduralni zapis by ani moc rychlost moc nezvetsil a rozhodne by to bylo hrozne na zapis. Je pravda ze objekty zerou pamet ale zase kdyz jde o testovaci ucel tak bych to tolik neresil.

Lamicz:
„Objekt je nejsložitější datový typ a bude vždy nejpomalejší, už z principu struktury neustálého fčního volání.“
Pokud to není specialita jen PHP, mohl bys to nějak rozvést? Nechápu, proč by měl být objekt vždycky nejpomalejší. Objekt jsou IMHO v podstatě data+funkce v jednom balení.

A neni to nahodou nejslozitejsi a nejpomalejsi dat. typ protoze toho nejvic obsahuje..

NejakyTom:
No jo, to je jasné, ale zase místo jednoho objektu je potřeba víc jiných datových typů. Srovnání (je to jen příklad):

A) Mám objekt mujbod třídy Bod, který má 3 proměnné jako atributy (x, y, z) a funkci zobraz(), která zobrazí bod v prostoru.
B) Mám 3 proměnné (mujbod_x, mujbod_y, mujbod_z) a funkci zobraz_bod(x, y, z), která zobrazí bod v prostoru.

Proč by v případě A to mělo být pomalejší než v případě B? V PHP asi jo, protože PHP program provádí rovnou a musí si za běhu objekt "seskládat" (zjistit si podle definice třídy, jaké má atributy atd.). Kompilovaný jazyk (např. C++) by ale tohle vyřešil už při překladu a s proměnnými v objektu by pak pracoval stejně rychle jako s proměnnými mimo objekt (nemám vyzkoušené, ale myslím, že zrovna u C++ to tak je, objekty jsou v podstatě rozšíření struktur).

imploder:
U objektu bude malý overhead, při volání (pro C++ jen u virtuální) funkce je potřeba se podívat do tabulky virtuálních metod, která že se to vlastně má zavolat. Volání konstruktorů a destruktorů také není úplně zadarmo. Řešit to pro php ale nemá moc smysl - php jakožto nekompilovaný jazyk je pomalé a řešit jestli to použítí objektů zpomalí o další 3% (číslo vycucané z prstu) je zbytečné.

Procedurální jazyk bude vždycky o něco málo rychlejší než OOP. Jedno moudro však říká, že OOP bude stejně rychlé, ne-li rychlejší, protože výsledný kód je zpravidla efektivnější. U PHP jde především o rychlost psaní, jednoduchost jazyka. Weby v C nikdy nebudou, drivery nebo operační systém v PHP také ne.

Johnik:
Pokud bude program pomalý, pak proto, že pracuje s daty o velikosti 500 objektu nebo to není dobře napsané. Pokud to přepíšeš do neobjektového zápisu, zrychlení téměř nepoznáš. Toť můj názor.

TomášK:
„Volání konstruktorů a destruktorů také není úplně zadarmo.“
Něco jako konstruktor se bude muset stejně volat: v tom příkladě s bodem to bude funkce, která proměnné naplní. Nemusím ji mít, stejně jako v C++ nemusím mít konstruktor.

„Řešit to pro php ale nemá moc smysl - php jakožto nekompilovaný jazyk je pomalé a řešit jestli to použítí objektů zpomalí o další 3% (číslo vycucané z prstu) je zbytečné.“
Myslím, že v PHP je to zpomalení bohužel mnohem větší než 3%. Viděl jsem na to nějaké benchmarky, už nevím kde.

„Procedurální jazyk bude vždycky o něco málo rychlejší než OOP.“
Když dělám v obou to samé (ne např. u OOP zbytečně virtuální funkce nebo u OOP konstruktor+destruktor a u procedurálního kódu nic+leak), proč by výsledný kód nemohl být stejně rychlý?

A nebylo by tohle lepsi resit jako je to resene u tveho prikladu? :) Tj za pomoci XML.

Johnik:
Záleží na tom, jestli chceš to HTML jenom jednou vytvořit, nebo ho chceš postupně upravovat. Pokud ho potřebuješ jenom celé najednou vytvořit, tak je nejefektivnější ho jenom vypisovat (jako se to dělá normálně při generování stránky v PHP), je zbytečné držet si ho v paměti jako objektový strom. Pokud ho chceš postupně upravovat, tak je objektový strom podle mě správné řešení.

imploder:
Při vytvoření objektu se vždy volá konstruktor, ať už implicitní nebo deklarovaný, vím, že třeba incializuje tabulku virtuálních metod (třebas prázdnou), možná ještě něco dalšího, nevím. Objekt má v paměti nějakou hlavičku (např. odkaz na tabulku virtuálních funkcí :-)), vinou toho se může někde nevejít do registrů. Pokud necháš překladač vygenerovat instrukce, jde vykoukat, že při použití objektu je jich tam o pár navíc.

TomášK:
OK, nezkoušel jsem to, nehádám se. Akorát mi teda připadá divné, že by překladač generoval zbytečně tabulku virtuálních funkcí i když v objektu žádné virtuální funkce nejsou a tím pádem žádná tabulka není potřeba. To by byl hodně hloupý překladač. Ale asi to má nějaký důvod, pokud to dělá.

[#11] Johnik
Tak tohle je třeba velice nešťastné a zbytečné použití OOP. Chápu to u jednoduchých věcí, jako např. při automatickém generování formulářů, ale tam nebude prvků 500, nebo u JS, kde je práce přímo pomocí HTML zdrojáku přes innerHTML občas napříč prohlížeči nefunkční, ale generovat celý HTML kód pomocí PHP je hrozný nesmysl. Možná to vypadá jako efektní řešení, ale rozhodně není efektivní - jak sám vidíš, objektový zápis je delší a méně přehledný, než přímo napsat HTML zdroják, a v tomhle případě to výkon může ošklivě zpomalit. Procedurální řešení už vůbec není cesta, cesta je prostě psát HTML.

imploder:
„Kompilovaný jazyk (např. C++) by ale tohle vyřešil už při překladu a s proměnnými v objektu by pak pracoval stejně rychle jako s proměnnými mimo objekt“
nemáš pravdu (mám za sebou C++ na MFF UK). Zrovna u C++ je režie na objekty dost markantní, protože myšlenka samotného C je psát na co nejnižší úrovni a "neprůhledná" (a nutná) režie objektů není malá; praktické zrychlení může spočívat v tom, co psal TomášK, že objektový zápis je většinou přehlednější než procedurální a tudíž se lépe programuje.
Další zajímavý fakt je, že třeba Java dnes díky run-time optimalizacím na virtuální Java machine dosahuje překvapivě časově lepších výsledků, než některé programy v C++ a jiných přímo překládaných jazycích do strojového kódu, kde run-time optimalizace nejsou možné.

imploder:
Taky jsem přemýšlel o tom, jestli ji bude tvořit, i když ji nepotřebuje. Nevím. Ale zkoušel jsem ty instrukce vygenerovat a nějaké navíc tam opravdu byly.

V C++ jsou myslím objekty poměrně průhledné - pokud bych pročetl manuály, tak budu vědět, jak přesně se to chová. Zdá se mi, že jde o konstrukci, destrukci, virtuální metody - každé může přidat pár instrukcí, ale čekal bych, že ten overhead bude pár procent. Neprůhledné to začne být, když do toho vstoupí garbage collector, který může dělat kdy chce, co chce. Mám pocit, že na jedné z přednášek (stejný zdroj jako AM :-)) zaznělo, že daleko pomalejší než samotné objekty jsou výjimky - potenciální skoky. Porovnávání jazyků je vždy zrádné, ale aspoň pro představu může sloužit benchmark game, kde je dáno několik problémů a každý může zaslat jeho řešení v libovolném jazyce. Nejlepší řešení jsou pak uvedena ve statistikách.