szybkość aplikacji internetowej, szybkość aplikacji internetowej, programowanie obiektowe Opcje

[psyduck411]

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.

[wNogachSpisz]

fukcjami a obiektowo.

Chodzi Ci o 'proceduralnie a obiektowo'.

Odpowiadam na pytanie - różnica jest kolosalna.

Ten post edytował wNogachSpisz 14.12.2011, 21:06:11

[Uriziel01]

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 (IMG:style_emoticons/default/wink.gif) Przy duzych projektach wydaje się to diabelnie trudne bez OOPHP.

Ten post edytował Uriziel01 15.12.2011, 07:53:25

[Crozin]

@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#.

[Uriziel01]

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' (IMG:style_emoticons/default/wink.gif)

Ten post edytował Uriziel01 15.12.2011, 10:17:46

[vokiel]

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.

[tehaha]

nie wiem jakiego typu miała by byc to strona aby bottleneck był na poziomie samego języka.

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.

[Crozin]

@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.

[Uriziel01]

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.

Ten post edytował Uriziel01 15.12.2011, 12:17:19