Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Szablony
Forum PHP.pl > Forum > PHP
tabbi
Witam,

mam pytanie co jest bardziej efektywne pod względem wydajności

KOD 1:
  1. <?php
  2. include_once("include/class_register.php");
  3. if($ok['Zalogowany']==1 && $ok['id']==$Session->ID){
  4. $uzytkownik=new Register();
  5. $row=$uzytkownik->DaneUser($Session->Var['idusera']);
  6. ?>
  7. <div id="sidebar">
  8. <h2>Panel użytkownika</h2>
  9. <div id="user-pane">
  10. <p>Witaj, <strong><?php echo $row['nick']; ?></strong></p>
  11. <p>Traffic: <strong><?php echo $row['traffic']; ?> MB</strong></p>
  12. <?php } ?>


KOD 2:

  1. <?php if($row['actcode']!=0){
  2. echo "<p>Brak potwierdzonego maila, sprawdź pocztę dopiero wtedy otrzymasz 200 mb</p>";
  3. <ul>
  4. <li><a href="pobierz">Pobierz pliki</a></li>
  5. <li><a href="twojepliki">Twoje pliki</a></li>
  6. <li><a href="kup">Kup doładowanie</a></li>
  7. <li><a href="pobrane">Ostatnio pobrane</a></li>
  8. <li><a href="doladowania">Doładowania</a></li>
  9. <li><a href="ustawienia">Ustawienia</a></li>
  10. <li><a href="poleceni">Statystyki poleconych</a></li>
  11. <li><a href="wyloguj">Wyloguj</a></li>'; ?>


Chodzi mi czy bardziej efektywne jest otwieranie kilka razy skryptu php czy też stosowanie echo i tam dodawanie tagów html ?

Nie chce obsługiwać szablonów itp. CHodzi mi tylko o te porównanie ?
kalmaceta
różnica rzędu 1/100 sekundy jet dla Ciebie ważna - na korzyść metody, która akurat w takim a nie innym kontekście jest szybsza i tyle, a zgłębiając swoją wiedzę dojdziesz i tak do wniosku, że najefektywniej korzystać z MVC i będziesz miał gdzieś wydajność.
Zyx
Pierwszy kod jest szybszy.

kalmaceta -> prosimy jaśniej. Wymieszałeś wszystko, co się dało.
kalmaceta
optymalizacja takich pierdół mija się z celem szczególnie w języku, który rozwija się przede wszystkim OOP.

  1. <?php
  2. echo "To jest szybkie $imie";
  3. echo "A może to jest szybkie ". $imie;
  4. echo 'A może to jest szybkie '.$imie;
  5. ?>
  6. A może to jest szybkie <?php echo $imie; ?>

Poza zbędnym użyciu cudzysłowów w drugim przypadku reszta jest porównywalna i zależy od stopnia skomplikowania, liczby podstawień, otwieranych zamykanych bloków itp. Reasumując w każdym przypadku jest inaczej. Wskazywanie co jest szybsze świadczy tylko ... po prostu nie świadczy dobrze.winksmiley.jpg
tabbi
  1. echo "A może to jest szybkie ". $imie;
Czemu coś takiego nie może być ?
kalmaceta
nie może być? może, tylko po co, cytuje za php.net:
Cytat
If the string is enclosed in double-quotes ("), PHP will interpret more escape sequences for special characters:
...
The most important feature of double-quoted strings is the fact that variable names will be expanded. See string parsing for details.
Mephistofeles
Pierwszy sposób jest lepszy, co nie oznacza, że szybszy. Wymienię kilka powodów:
-kolorowanie składni, zazwyczaj łańcuchy w echo mają jeden kolor
-zamykamy PHP w bloku PHP i HTML mamy osobno, można powiedzieć, że to pierwszy etap oddzielenia kodu od treści
-jeśli jest to fragment odpowiedzialny za wygląd strony, to HTML powinien przewodzić, a PHP być dodatkiem
Zyx
Powtarzam: jest szybszy, mierzyłem kiedyś winksmiley.jpg. I wbrew pozorom, przy bardziej rozbudowanych szablonach różnica była całkiem zauważalna.
kalmaceta
jaka różnica, przy jakich szablonach? poproszę o konkretne dane - bez dowodów = bullshit

bo, nawet w pierwszy sposobie, bardziej złożone szablony, w których nie brakuje pętli parser php i tak musi manipulować HTML pomiędzy <?php ?>.
thek
Kalmaceta... Popatrz na to tak. Wyjście i wyjście z interpretera to naprawdę wartości niemal pomijalne. To co poza nim - leci wprost - nie przetwarzane nijak. Tymczasem echo nawet jest już funkcją ( właściwie to konstruktem języka jeśli jesteśmy purystami ), która i tak musi przejść przez interpreter. Zastosowanie " będzie wolniejsze niż ' bo wiadomo, że w podwójnym będzie "szukał" zmiennych php do rozwinięcia. Ale nawet ' ma pewien narzut czasowy związany z faktem, że interpreter pracuje i musi przetwarzać jego czy kolejne instrukcje. Lepiej jest go więc wywoływać tylko kiedy jest to potrzebne niż pozwolić mu pracować cały czas. Praca interpretera spowalnia całość.
kalmaceta
po 1. nie twierdze, że któreś jest szybsze - to sensu nie ma, ja to wiem i Ty pewnie też,
po 2. "wartości pomijalne" nie bardzo, zakładamy złożony szablon
po 3. przy pętlach zawartość pomiędzy <?php ?> i tak trafia do bufora podręcznego do replikowania,
po 4. interpreter cały czas pracuje, a wykonuje tylko to pomiędzy <? ?> z resztą jak trzeba zapamiętać też działa,
po 5. to że jest HTML w pliku php nie znaczy że jest pomijany i wysyłany do przeglądarki i jest super, ale trafia do bufora wyjściowego silnika.
po 6. echo jak wspominiałeś nie jest funkcją de facto, na op kodach jest mimo wszytko szybciej,
kiler129
Ja się odniosę natomiast do dbl quote vs single quote - g... prawda że dbl jest wolniejsze od single.
Źródło? Proszę bardzo: http://www.phpbench.com/

A co do samej optymalizacji o 1/100 sekundy ... to dość sporo, 1/100 sekundy to 10ms - w tyle to porządny CMS całą www pokaże.
kalmaceta
po 1. g... prawda to te testy - u mnie zawsze na korzyść ' - http://ideone.com/wHE26
po 2. 1/100sek. to nie duży narzut w stosunku do tego co funduje OOP w większości CMS
Zyx
O rany, a skąd Ci wezmę benchmark, który robiłem dobre 5 lat temu? Mało Ci, że ze względu na jego wyniki zadałem sobie trud przepisania całego mechanizmu generowania kodu we wczesnych wersjach OPT? Ponadto różnicę w czasie bardzo łatwo wytłumaczyć. Bufor wyjściowy skryptu obsługuje tylko dwie operacje, które mogą być zainicjowane przez skrypt: doklejanie nowego tekstu i konwersja do wielkiego ciągu tekstowego (ob_get_clean()). Zatem, skoro nie musimy mieć dostępu w dowolne miejsce bufora, możemy zwłaszcza pierwszą operację zaimplementować dużo wydajniej, tworząc po prostu listę z kolejno doklejanymi kawałkami kodu. Gdy operujemy na ciągu tekstowym, PHP musi zakładać swobodny dostęp do niego, zatem przy doklejaniu musi realokować pamięć dla całego tekstu. Jeśli w danym miejscu nie będzie już wolnej pamięci, aby poszerzyć tekst o wymaganą ilość bajtów, trzeba zaalokować nowy blok i skopiować dotychczasową zawartość. Ale dobra, chcesz, to Ci zrobię takowy raz jeszcze.

Ad. podwójnych i pojedynczych cudzysłowów - nie chcę nic mówić, ale na PHP 5.3.4:

  1. <?php
  2. $time = microtime(true);
  3. $foo = 'bar';
  4. for($i = 0; $i < 1000000; $i++)
  5. {
  6. $text = "foo bar joe foo bar joe foo $foo joe foo bar joe foo bar joe $foo joe";
  7. }
  8. echo (microtime(true) - $time);


~0,62 s

  1. <?php
  2. $time = microtime(true);
  3. $foo = 'bar';
  4. for($i = 0; $i < 1000000; $i++)
  5. {
  6. $text = 'foo bar joe foo bar joe foo '.$foo.' joe foo bar joe foo bar joe '.$foo.' joe';
  7. }
  8. echo (microtime(true) - $time);


~0,71 s

Natomiast jeszcze kilka lat temu potwierdzam, że cudzysłowy były duuuużo wolniejsze, zwłaszcza jak się używało kodów formatujących.

Cytat
1/100sek. to nie duży narzut w stosunku do tego co funduje OOP w większości CMS


O panie, jakbym stosował Twoje metody, to byłbym chyba autorem najwolniejszych skryptów w całym Internecie smile.gif. Jak 1/100 sekundy to mało, kiedy ja właśnie pracuję nad dość rozbudowaną stroną, która na moim kilkuletnim komputerku, i to z włączonymi opcjami debugowymi ma średni czas przetwarzania rzędu... 2/100 sekundy? smile.gif Wiem, różnice w sprzęcie robią swoje, ale żeby wypowiadać się o 1/100 sekundy warto najpierw podać jakiś punkt odniesienia, bo jedna setna jednej setnej nierówna.

Ogólnie przy mierzeniu czegokolwiek trzeba mieć na uwadze, że język cały czas się rozwija. Coś, co jeszcze 3 lata temu było wolne, teraz mogło dostać kopa dzięki optymalizacjom. Przykładowo, w PHP 5.4 ma pojawić się całkiem sporo ponoć niezłych optymalizacji tablic z haszowaniem, które są wykorzystywane m.in. do implementacji typu array oraz wszelkich rejestrów funkcji, metod itd.
kalmaceta
@Zyx widzisz nie wiesz na co odpowiadasz tu chodziło o porównanie ' z " z czystym tekstem

  1. echo "jakis ldlugi tekst" . $cos;
  2. echo 'jakis ldlugi tekst' . $cos;

różnice są niewielki na korzyść ', ale w dyskusje dalszą wchodzić nie będę bo faktycznie kiedyś to inaczej wyglądało


ad. 1/100 sek. To mnie rozbawiłeś. Przeczytaj w jakim kontekście wymieniam te wartości, a mianowicie w kontekście rozbudowanego OOP. Nie chodzi tu o wspomniane 10ms., czy jakaś strona się ładuje szybciej, czy mamy _once czy nie czy " czy ', czy jest __autoload czy nie czy for czy foreach - po prostu dotyczyło to tezy - tutaj nie warto szukać wydajności bo zysk jest mierny,, złożony preg_, imagecopy... potrafi trwać dłużej. Więc o co ta dyskusja, chcesz wydajności odrzuć OOP, chcesz komofortu pisania pogódź się z 1/100sek.
Zyx
Przeczytałem i podałem Ci, że pracuję nad rozbudowanym systemem, który wykonuje się na moim kilkuletnim komputerku. A jakbyś zapytał o szczegóły, nawet bym Ci powiedział, że te 2/100 sekundy wyciąga system, w którym jest obiektówka i nic więcej. Same klasy, metody i obiekty współpracujące ze sobą. Twierdzenie, że należy wywalić obiektówkę to demagogia i populizm, bo wystarczy by ta obiektówka zawierała jakieś nietrywialne algorytmy i już staje się jedynie dodatkiem. Jeśli wszystkie skrypty tej klasy są napisane wyłącznie w OOP, wtedy wracamy do punktu, w którym dobrze napisany algorytm, poprawnie użyta konstrukcja języka ma znaczenie. A ma znaczenie tym większe, im częściej musimy wykonać dany kawałek kodu.

Niedawno przejechałem wspomniany właśnie skrypt z ciężką obiektówką profilerem i wiesz, co mi wyszło? Że 40% czasu z tych dwóch setnych sekundy zajmuje 10-linijkowy, strukturalny do bólu kawałek kodu w autoloaderze, który tłumaczy nazwy klas na ścieżki w systemie plików, a dalsze 20% to również strukturalna kompilacja i hydracja wyników jednego zapytania w Doctrine. Wymieniam autoloader na korzystający z mapy, zyskuję 12% na całym żądaniu HTTP, przepisuję zapytanie DQL na SQL, mam kolejne kilkanaście procent, a przecież ograniczyłem się tylko do zastąpienia dwóch "nicnieznaczących algorytmów" i paru linijek "nieistotnego kodu"... zatem wracamy do punktu wyjścia: gdybym stosował się do Twoich rad, zamiast po prostu pomyśleć, co się często wykonuje, a co rzadko, byłbym twórcą najwolniejszych skryptów w Internecie. Pozdrawiam.
matrik
łoł, możecie mnie obsunąć albo i nie, ale
  1. echo "Pokaż $zmienna";
  2. echo 'Pokaż '.$zmienna;

Pierwsze echo stosuje się bardzo rzadko, jeśli string jest krótki, natomiast drugie stosuje się do utworzenia ew. komunikatów skryptu. Np.
  1. if($error===true){
  2. echo 'Nie odnaleziono '.$elementu.' w adresie '.$dir;
  3. }


MVC to już inna droga, kolega natomiast pisze prosty skrypt strukturalny, więc nie da się zaprzeczyć, że samo to łamie standardy PHP5:
1. include jest przestarzałe moim zdaniem, stosuje jednak require_once bo nie wywala błędów a konkretnie sprawdza skrypt czy plik istnieje przez file_exsists
2. wykorzystanie smarty to jedyna droga do optymalizacji, pisanie własnego silnika może być pożyteczne jeśli nie będzie on dosyć bezsensowny.
3. każdy pisze na swój sposób, ja jednak jeśli nie chce mieć problemów ze skryptem, a kawałek kodu jest na prawdę taki, że się nie opłaca pisać w każdej jednej linii echo to trzeba w takim przypadku:
  1. <form>
  2. HTML'.$zmienna.'
  3. </form>
  4. ';


cudzysłów " " wykorzystuję także w zapytaniach SQL jeśli wartość jest nie dłuższa niż 2-5 znaków lub jest liczbą wysyłaną do pola INT



Zyx, właśnie 'bajery' w nowych skryptach gubią ludzi, uczy to ich lenistwa, przecież jak samemu się czegoś nie napisze to PHP tego nie zrobi, a jeszcze lepiej, jak nie podasz co ma zrobić to nie będzie działać.
Po co tu korzystać z takich bajerów jak spowalniają one prace skryptu, szczególnie tych dynamicznych.

Pozdro
kalmaceta
Zyx dlaczego demoscena pracuje na niskopoziomowych językach strukturalnych czemu facebook przepisuje i kompiluje kod pod c++ - bo jest szybsze. OOP, to kolejny poziom abstrakcji i tego nic nie zmieni a większość algorytmów, wydajnych, operuje na prostych strukturach - to nie demagogia. Nie jestem przeciwko OOP wręcz przeciwnie, ale licze się z tym co za tym idzie. Nie oceniam Twojego kodu, Twojej pracy bo jej po prostu nie widze i nie o to chodzi - chodzi o to że jak sam napisałeś optymalizuje się algorytmy, zapytani do bazy, strukturę, routing itd. a nie echo.
matrik
kalmaceta ja już rozmawiałem z taką osobą co też miała takie zdanie, i to jest w pewnym sensie prawdą, ale dlaczego w takim razie czepiasz się PHP jeśli nie możesz w nim pisać języków C++?
Dlaczego nie mogą zrobić stron www w C++?
Przecież to PHP czyli program na 'PC'.

Nie wiem dlaczego w tym wątku są brane pod uwagę inne języki programowania..
Crozin
Cytat
Pierwsze echo stosuje się bardzo rzadko, jeśli string jest krótki, natomiast drugie stosuje się do utworzenia ew. komunikatów skryptu. Np.
  1. // Jeden konkretny powód, dla którego nie może być niby
  2. echo "Nie odnaleziono $elementu w adresie $dir";
  3. //czy
  4. printf('Nie odnaleziono %s w adresie %s', $element, $dir);
Cytat
MVC to już inna droga, kolega natomiast pisze prosty skrypt strukturalny, więc nie da się zaprzeczyć, że samo to łamie standardy PHP5:
PHP5 ma bibliotekę standardową w dziewięćdziesięciu-paru procentach strukturalną, a i te parę procent niby obiektowego kodu bardzo często obiektowe nie jest. Więc jakie niby standardy łamie?
Cytat
1. include jest przestarzałe moim zdaniem, stosuje jednak require_once bo nie wywala błędów a konkretnie sprawdza skrypt czy plik istnieje przez file_exsists
Mam złą wiadomość. include i require to to samo (z wyjątkiem poziomu rzucanego błędu). Wersje (_once) również niczym się nie różnią. Obie te funkcje sprawdzają czy plik istnieje (swoją drogą nie robią tego przez file_exists).
Cytat
2. wykorzystanie smarty to jedyna droga do optymalizacji, pisanie własnego silnika może być pożyteczne jeśli nie będzie on dosyć bezsensowny.
Jedyna prawdziwa droga powiadasz? Smarty jest bardzo słabym projektem, w dodatku na tle innych tzw. systemów szablonów wypada dosyć słabo.
Cytat
3. każdy pisze na swój sposób
Nie, powinno się pisać wg ustalonych konwencji. Co prawda w PHP jest z tym ogromny problem, ponieważ często brak takowych albo istnieje kilka różnych, pokrywających się.
Cytat
ja jednak jeśli nie chce mieć problemów ze skryptem, a kawałek kodu jest na prawdę taki, że się nie opłaca pisać w każdej jednej linii echo to trzeba w takim przypadku:
Nic nie trzeba, co najwyżej można.
Cytat
cudzysłów " " wykorzystuję także w zapytaniach SQL jeśli wartość jest nie dłuższa niż 2-5 znaków lub jest liczbą wysyłaną do pola INT
Tego to już w ogóle nie rozumiem.
Cytat
przecież jak samemu się czegoś nie napisze to PHP tego nie zrobi
Jeden z największych problemów PHP to właśnie robienie czegoś za programistę w tle. Idioto-odporność tego języka jest na tak wysokim poziomie, że stwarza więcej problemów niż ich rozwiązuje.
Cytat
Po co tu korzystać z takich bajerów jak spowalniają one prace skryptu, szczególnie tych dynamicznych.
Bo przyśpieszają pracę programisty? Czas programisty kosztuje dużo więcej niż czas procesora.
kalmaceta
matrik a dlaczego nie możesz zrobić strony w c++? można, kwestia bezpieczeństwa (na współdzielonych) i chęci i organizacji i stopnia trudności c++ do php.
inne języki brane tylko po to żeby wytłumaczyć, że OOP to komfort pracy kosztem wydajności, tylko w tym kontekście.

edit: a i gwoli ścisłości nie czepiam się PHP, OOP czy czegoś tam oprócz sensu pytania o wydajność wątkotwórcy.
Mephistofeles
Z takiej samej przyczyny nie pisze się stron w C++ jak nie robi się aplikacji okienkowych w PHP. Oba języki zostały przystosowane do czego innego.
kalmaceta
@Mephistofeles zasłyszane i nie zupełnie prawdziwe w odniesieniu do np. c++/javy/ptyhona. słyszałeś o czymś takim jak CLR lub HipHop
Mephistofeles
Oczywiście, że słyszałem. Tylko po co pisać kompilator/właściwie translator PHP do C++, zamiast od razu w C++? Bo tak jest łatwiej i o to mi chodziło. PHP ma wbudowaną obsługę tego, co potrzeba na stronach, do tego jest łatwy do nauczenia.
kalmaceta
oczywiście masz racje jeśli chodzi o prostotę. ale po Twojej poprzedniej wypowiedzi wnioskowałem, że wykluczasz c++ z takiego wykorzystania, ale poza "prostotą php i dostępności na serwerach (problemów dla adminów tylko) jest to bardzo dobre rozwiązanie.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.