Szablony Opcje

[tabbi]

Witam,

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

KOD 1:

[PHP] pobierz, plaintext 
<?php
include_once("include/class_register.php");
if($ok['Zalogowany']==1 && $ok['id']==$Session->ID){
$uzytkownik=new Register();
$row=$uzytkownik->DaneUser($Session->Var['idusera']);
?>
 <div id="sidebar">
  <h2>Panel użytkownika</h2>
  <div id="user-pane">
    <p>Witaj, <strong><?php echo $row['nick']; ?></strong></p>
    <p>Traffic: <strong><?php echo $row['traffic']; ?> MB</strong></p>
<?php } ?>
[PHP] pobierz, plaintext 

KOD 2:

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

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.

[PHP] pobierz, plaintext 
<?php
echo "To jest szybkie $imie";
echo "A może to jest szybkie ". $imie;
echo 'A może to jest szybkie '.$imie;
?>
A może to jest szybkie <?php echo $imie; ?>
[PHP] pobierz, plaintext 

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.

[tabbi]

[PHP] pobierz, plaintext 
echo "A może to jest szybkie ". $imie;
[PHP] pobierz, plaintext 

Czemu coś takiego nie może być ?

[kalmaceta]

nie może być? może, tylko po co, cytuje za php.net:

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.

Ten post edytował kalmaceta 21.01.2011, 17:54:46

[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ś . I wbrew pozorom, przy bardziej rozbudowanych szablonach różnica była całkiem zauważalna.

Ten post edytował Zyx 21.01.2011, 20:53:29

[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 ?>.

Ten post edytował kalmaceta 22.01.2011, 00:00:29

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

Ten post edytował kiler129 22.01.2011, 00:34:02

[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:

[PHP] pobierz, plaintext 
<?php
$time = microtime(true);
$foo = 'bar';
for($i = 0; $i < 1000000; $i++)
{
	$text = "foo bar joe foo bar joe foo $foo joe foo bar joe foo bar joe $foo joe";
}
echo (microtime(true) - $time);
[PHP] pobierz, plaintext 

~0,62 s

[PHP] pobierz, plaintext 
<?php
$time = microtime(true);
$foo = 'bar';
for($i = 0; $i < 1000000; $i++)
{
	$text = 'foo bar joe foo bar joe foo '.$foo.' joe foo bar joe foo bar joe '.$foo.' joe';
}
echo (microtime(true) - $time);
[PHP] pobierz, plaintext 

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

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

Ten post edytował Zyx 22.01.2011, 08:01:07

[kalmaceta]

@Zyx widzisz nie wiesz na co odpowiadasz tu chodziło o porównanie ' z " z czystym tekstem

[PHP] pobierz, plaintext 
echo "jakis ldlugi tekst" . $cos;
echo 'jakis ldlugi tekst' . $cos;
[PHP] pobierz, plaintext 

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.

Ten post edytował kalmaceta 22.01.2011, 11:39:06

[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

[PHP] pobierz, plaintext 
echo "Pokaż $zmienna";
echo 'Pokaż '.$zmienna;
[PHP] pobierz, plaintext 

Pierwsze echo stosuje się bardzo rzadko, jeśli string jest krótki, natomiast drugie stosuje się do utworzenia ew. komunikatów skryptu. Np.

[PHP] pobierz, plaintext 
if($error===true){
echo 'Nie odnaleziono '.$elementu.' w adresie '.$dir;
}
[PHP] pobierz, plaintext 

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:

[PHP] pobierz, plaintext 
echo '
<form>
HTML'.$zmienna.'
</form>
';
[PHP] pobierz, plaintext 

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]

Pierwsze echo stosuje się bardzo rzadko, jeśli string jest krótki, natomiast drugie stosuje się do utworzenia ew. komunikatów skryptu. Np.

[PHP] pobierz, plaintext 
// Jeden konkretny powód, dla którego nie może być niby
echo "Nie odnaleziono $elementu w adresie $dir";
//czy
printf('Nie odnaleziono %s w adresie %s', $element, $dir);
[PHP] pobierz, plaintext 

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?

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

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.

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

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.

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.

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.

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.