wiem ze strona sie ładuję szybciej w czystym HTML aniżeli wykorzystując skrypt PHP.
ma pytanie czy jest zasadnicza różnica w tworzeniu takiej samej aplikacji fukcjami a obiektowo.
albo zakładając ze np aplikacja zawiera więcej niepotrzebnych includowanych plików.

dla przykładu czy jest różnica przy tworzeniu strony w prostym frameworku, czy potężnym jak zend lub symfony?
czy jest różnica zrobienia sstrony na frameworku, a "prawie statyczną" wykorzystując jakieś tam funkcje.

Chodzi Ci o 'proceduralnie a obiektowo'.

Odpowiadam na pytanie - różnica jest kolosalna.

Pisanie obiektowo w PHP zawsze będzie wolniejsze, ze względu na tworzenie abstrakcyjnych instancji objektów których tak na prawdę nie potrzebujemy (są one jedynie kontenerami dla naszych struktur i danych), w dodatku pisząc OOPHP łatwo wpaść w błędne koło tworzenia zbędnych warstw abstrakcji, tworząc jakiś własny FW łątwo zapomnieć o bożym świecie i zasypać wszędzie kod set'erami i get'ami. Podsumowując, wszystko może być dobre jeżeli jest używanę z rozwagą i umiarem. A na plus obiektowego pisania zaliczył bym rozdzielenie i posegregowanie kodu, struktur. Daje to większe pole do popisu przy projektowaniu aplikacji, co w rezultacie może nam zaoszczędzić masę czasu tworząc 'protezowy' pod dla miejsc w których czegoś nie przewidzieliśmy. Objektowo napisany kod jest bardziej elastyczny i modularny.
Mimo wszystko na koniec benchmark (choć nie łatwo znaleść w internecie coś sensownego na ten temat):
http://xodian.net/serendipity/index.php?/a...l-vs.-Ruby.html
Jak widzimy najwydajniejsze jest pisanie bez użycia objektów, ba! nawet bez użycia funkcji. Zastanawia mnie tylko czy istnieje człowiek zdolny ogarnąć chociażby małej wielkości projekt bez użycia funkcji Przy duzych projektach wydaje się to diabelnie trudne bez OOPHP.

@Uriziel01: Nie mam w tej chwili czasu przeczytać benchmarka jakiego podrzuciłeś, ale czy on naprawdę opiera się na dwóch testach - "hello world" oraz "for (...) { ... }"? Taki test jest nic nie warty. Co więcej jeżeli wąskim gardłem aplikacji jest sam język - jego charakterystyka - to znak, że trzeba rozważyć przejście na bezwzględnie lepszą (dla komputera) platformę jaką będzie Java czy C#.

Przejść na Jave ? Nie dziękuję, to już wole mój cały kod przepisać na C. Wiem że ten kod nie przedstawia faktycznych warunków, ale chyba wyraźnie napisałem że nie da się znaleść miarodajnych testów w tej materii (OO vs proceduralne vs goły kod) a sam raczej nie mam czasu aby je robić, przytoczony link jest raczej żartem per problemów z wydajnością kodu objektowego. Z resztą jest tego troszkę w necie, poza tym PHP prawie nigdy nie jest wąskim gardłem, może nim być sam serwer/router/bazaSQL a nawet przepustowość łącza w danej serwerowni, ale nie wiem jakiego typu miała by byc to strona aby bottleneck był na poziomie samego języka.

P.s-może faktycznie w ostatnim zdaniu niezbyt dosanie pokazałem że jest to żart. To jest troszkę tak jak z porównaniem Fiata126P i Mercedesa S klasy. Niby maluszek pali mniej, jest tańszy w utrzymaniu a podczas stłuczki możemy go zostawić w rowie, ale w ostatecznym rozrachunku jakość użytkownia jest niewspółmierna, lepiej płacić drożej i żyć w 'luksusie'

Prędkość ładowania się strony w najmniejszym stopniu zależy od tego, czy kod został napisany obiektowo, czy nie. Źle napisany projekt strukturalnie może być bardziej wymagający niż dobrze napisany obiektowo. Dyskusja w tym kierunku nie ma większego sensu. Różnica jest przy kodzie generowanym a statycznymi plikami, ale są tu inne aspekty, które trzeba brać po uwagę.

W dzisiejszych czasach koszt serwerów w porównaniu do kosztu pracy ludzkiej jest śmiesznie niski. Przykładowo 1 developer pisze aplikację z wykorzystaniem popularnego frameworka w 2 m-ce, drugi pisze to samo strukturalnie od zera w 3-4 miesiące. Różnica z wielu względów przemawia za tym pierwszym: aplikacja pojawia się na rynku wcześniej, być może akurat miesiąc przed konkurencją. Za te dodatkowe 2 m-ce pracy programisty można opłacić przez następny rok serwer. Przykładowo po roku potrzebujemy zmian. W pierwszym przypadku wdrożenie nowego programisty znającego framework i napisanie tych poprawek zajmie mniej czasu niż samo wdrożenie się w kod w drugim przypadku.

Wydaje mi się, że chodziło raczej o to, że jeżeli przy tworzeniu aplikacji miałbyś rozważać między kodem proceduralnym a obiektowym ze względu na teoretycznie większą wydajność kodu proceduralnego to znaczy, że trzeba zmienić język bo php sam w sobie jest wolny w porównaniu do innych.

Osobiście wydaje mi się, że kod proceduralny będzie szybszy tylko w przypadku prostych aplikacji, dużą aplikację ciężko by było napisać wydajnie bez obiektów, może teoretycznie się da, ale w praktyce to już nie bardzo, kodu byłoby strasznie dużo i jego wydajność zmniejszała by się w raz z rozbudową aplikacji i wprowadzaniem zmian. Do tego dochodzą jeszcze czynniki ekonomiczne, o których wspomniał @Vokiel, więc szczerze mówiąc nie rozumiem w jakim celu autor zadał to pytanie, bo mam nadzieje, że nie rozważa budowania aplikacji bez oop.

@tehaha: Można bez większych problemów pisać w pełni strukturalnie aplikacje - pytanie tylko po co.
@Uriziel01: PHP sam w sobie bardzo szybko staje się wąskim gardłem gdy trzeba zrobić coś co będzie napisane w PHP, tj. główne zadanie zostanie zrealizowane kodem PHP, a nie odwołaniami do funkcji z biblioteki standardowej / rozszerzeń napisanych w C. Ileż to razy dochodzi do sytuacji gdzie używa się do rozwiązywania pewnych problemów narzędzi kompletnie nieadekwatnych do stawianych przed nimi zadaniami tylko dlatego, że są to "standardowe funkcje" i całość będzie działać szybciej. Idealnym przykładem będą tutaj wyrażenia regularne. Zwróć uwagę na to, że możesz zapomnieć o tym by w PHP napisać własny mechanizm wyrażeń regularnych, parser XML czy jakieś narzędzie manipulujące obrazami, które będzie efektywniejsze niż wbudowane. Nawet jeżeli sposób ich działania będzie w pełni poprawny, a użyte algorytmy lepsze niż te w wbudowanych narzędziach ograniczy Cię język.

Hmmm, to fakt. Nie pomyślałem pod tym kątem. Ale powiedzmy sobie szczerze Już utarło się że wymagające wysokiej wydajności funkcjonalności są realizowane przez zewnętrzne biblioteki, często przepisane na C. A wracając do treści pytania, różnica jest taka że statyczna strona z 'pewnymi funkcjami' jak to zostało zgrabnie ujęte w pewnym momencie trafi na ścianę, będzie to ilość funkcji, możliwość ich segregacji, zachowanie we własnym zakresie spójnych interfejsów, realizacja oddzielenia kodu HTML od logiki biznesowej a nawet proste konflikty w nazwach i zpamietaniu miliona prefixów i suffixów które pozwolna nam sie po tym poruszać. Mozna co prawda tę ścianę przesuwać ale niestety i to dobiegnie w pewnym momencie ku końcowi. Kod obiektowy (poprawnie napisany) nie ma tak znacząco wzrastającej komplikacji kodu wraz z dodawaniem nowych funkcjonalności.