PHP - pojedyncze nawiasy, optymalizacja i bzdury w tutorialach

[slawek22]

Postanowiłem obalić mit, jakoby rodzaj nawiasów wpływał na szybkość wykonywania kodu PHP. Takie komputerowe szamaństwo generuje tylko problemy tym którzy praktykują te zabobony i ludziom którzy muszą po nich poprawiać "wyczarowany" kod

Optymalizacja

Zamiana znaku ' na podwójny cudzysłów to optymalizacja automatyczna. Jeśli miałoby to poprawić wydajność to interpreter sam by to zrobił. Jeśli nie zrobiłby tego interpreter to akcelerator zenda i zend encoder. Optymalizacja jest tak banalna, że nawet małpa mogłaby ją wykonać. Dla Zend to nie problem napisać parę linijek kodu wykonywanego poziom niżej który zrobi to samo z automatu.

Można się sprzeczać, czy lepiej zainstalować dodatkowe oprogramowanie czy zamieniać swój kod w śmietnik, ale tylko jeśli takie działanie niesie jakiekolwiek korzyści.

1. Wydajność poszczególnych metod:

Klasyczny przypadek "programisty php". Osoba w tutorialu radzi używać kropek i pojedynczych cudzysłowów po to bo "PHP wykona to szybciej" a zaraz potem przemiela HTML systemem szablonów który cały HTML strony przerabia przy użyciu tysięcy linii kodu, dziesiątek wolnych instrukcji strpos i jeszcze wolniejszych regexów. Ile regexów jest w samym parserze bbCode forum phpBB2? Około 70.

Różnice rzędu setnych części sekundy przy milionie operacji sklejania łańcuchów:

1 000 000 x pojedynczy cudzysłów + kropka : 0.657688140869

1 000 000 x podwojny cudzysłów : 0.546454906464

1 000 000 x podwojny cudzysłów + kropka : 0.659504890442

Gdzie tu miejsce na optymalizację? Taka "optymalizacja" tylko psuje czytelność kodu i marnuje czas. W rezultacie prowadzi do powstawania niepotrzebnych błędów. Osoby które ją proponują nie miały czasu na napisanie prostej pętli i sprawdzenie jak to NA PRAWDĘ wpływa na wydajność. Czy osoby które nie wiedzą jak zmierzyć czas wykonywania instrukcji mogą mieć pojęcie o optymalizacji. Pewnie myślą, że mogą

Wydajność systemu szablonów

Teraz wystarczy porównać ile czasu zajmnie przeparsowanie prostego dokumentu HTML, tylko 10000 razy przy użyciu zoptymalizowanego systemu szablonów (który jest o wiele szybszy niż smarty i wydajniejszy niż parser bbCode):

10 000 x parser (dokument 20kb): 18.6068100929

10 000 x parser (dokument 5kb): 7.33778190613

Przewidywany czas operacji dla 1 000 000 parsowań (dokument 20kb): 1800 sekund / pół godziny

Przewidywany czas operacji dla 1 000 000 parsowań (dokument 7kb): 12 minut.

Wydajność file_get_content

Czy test systemu szablonów jest dobry? W "normalnych" warunkach należy dodać czas odczytu pliku (użyty system raz przeczytany plik umieszcza w cache pamięciowym). W normalnych warunkach parsujemy szablon kilka razy / page hit. Cache pamięciowe zostaje opróżnione pod koniec wykonywania skryptu, dlatego do sumy czasu należy dodać czas operacji file_get_content/include użytej do wczytania szablonu, odpowiednio:

10000 x file_get_contents parser : 5.79139709473

Podsumowując: przeparsowanie milion razy 7kb kodu HTML ~ 21 minut. Samo wczytanie pliku szablonu milion razy zajmuje ponad 7 minut. Milion operacji sklejania łańcuchów: zawsze poniżej sekundy.

Tutaj przykład dobrze zrobionej optymalizacji funkcji: https://www.forum.optymalizacja.com/index.php?showtopic=50038

Niestety trzeba przy tym trochę pomyśleć a nie tylko zmienić rodzaj cudzysłowu czy rodzaj nawiasu.

Kod użyty do pomiaru czasu: PM.

[ghosti]

<?php
//set_time_limit(0);
function get_mtime(){
list($usec,$sec)=explode(' ',microtime());
return((float)$usec+(float)$sec);
} 

$start=get_mtime();
$x='';
for($i=0;$i<4000000;$i++)
$x=$x+'Ux7A9_spAm_S82Ksc';

$finish=get_mtime();
echo $finish-$start;
?>

$x.='Ux7A9_spAm_S82Ksc';

12.894020795822

12.853130817413

12.850792884827

$x.="Ux7A9_spAm_S82Ksc";

12.82448220253

12.866347789764

12.835007190704

$x+='Ux7A9_spAm_S82Ksc';

1.0507550239563

1.0664350986481

1.0655188560486

1.0578978061676

$x+="Ux7A9_spAm_S82Ksc";

1.0515909194946

1.0569579601288

1.0595800876617

1.0480599403381

$x=$x+"Ux7A9_spAm_S82Ksc";

1.1541199684143

1.1768641471863

$x=$x+'Ux7A9_spAm_S82Ksc';

1.1770610809326

1.1741790771484

Nie wiem czemu z . tak wolno byc moze dlatego, ze dodawany jest caly czas ten sam lancuch i dla + jest to ladnie zoptymalizowane. Moze jutro zrobie z losowaniem stringa z kazdym obrotem petli innego.

Aha testowane oczywiscie na PHP 5.2.5.

[ghosti]

Zmniejszylem liczbe obrotow petli na 400000.

$x.=get_random();

11.493499040604

12.858752012253

13.111472129822

$x+=get_random();

13.20941901207

12.825392007828

13.302996873856

get_random - generuje 18 znakowy lancuch ze znakow [a-zA-z0-9_]

Podsumowujac +/. bez wiekszych roznic, ""/'' takze bez wiekszej roznicy

[k0rnik]

$x=$x+'Ux7A9_spAm_S82Ksc';
1.1770610809326
1.1741790771484

Nie wiem czemu z . tak wolno byc moze dlatego, ze dodawany jest caly czas ten sam lancuch i dla + jest to ladnie zoptymalizowane.

Z '+' tak szybko, bo $x=$x+'Ux7A9_spAm_S82Ksc' w każdej pętli daje w wyniku liczbę 0, zamiast łańcucha , a dla kropki łańcuch ciągle się wydłuża. Testowanie '+' w przypadku stringów mija się z celem...

[slawek22]

W końcu... ktoś z Zenda zdementował bzdury o pojedynczych łańcuchach, konkatenacji i innych "świetnych optymalizacjach" przedstawianych w polskiej i zagranicznej "prasie kolorowej" ... ale trzeba było żeby te bzdury powtórzył aż ktoś z google. W sumie lepiej późno niż wcale, polecam artykuł

https://webhosting.pl/Naiwne.porady.z.Mount...a.pojecia.o.PHP

„używaj pojedynczych cudzysłowów dla łańcuchów”, jest również radą prosto z jakiejś dziwnej bajki. W PHP 5.2 i 5.3, parsowanie łańcuchów zamkniętych w podwójnych cudzysłowach na pewno nie jest wolniejsze, niż wypadku użycia cudzysłowów pojedynczych – a jak pokazuje Raskind, często nawet szybsze.

[...]

Zdaniem Raskinda rady podane przez Erika Higginsa dotyczą bardzo starych wersji języka – „nawet wersji trzeciej”, natomiast nie mają żadnego zastosowania we współczesnych warunkach. Higgins próbował się bronić, wyjaśniając, że chodziło mu o poprawki właśnie dla tych starych wersji interpretera

[pawloski]

u mnie też "" są szybsze niż '' + sklejanie kropką

od najszybszego do najwolniejszego:

echo 'tekst ', $zmienna, ' tekst';

echo "tekst {$zmienna} tekst";

echo "tekst $zmienna tekst";

echo 'tekst '.$zmienna.' tekst';

[Filip_]

Czyli można rozumieć, że różnica jest na tyle mała, że bez różnicy jest czy się stosuje "" bądź '' ? czy też + bądź . ?

[Tomahawk]

Zamiana znaku ' na podwójny cudzysłów to optymalizacja automatyczna. Jeśli miałoby to poprawić wydajność to interpreter sam by to zrobił. Jeśli nie zrobiłby tego interpreter to akcelerator zenda i zend encoder. Optymalizacja jest tak banalna, że nawet małpa mogłaby ją wykonać. Dla Zend to nie problem napisać parę linijek kodu wykonywanego poziom niżej który zrobi to samo z automatu.

Akurat mitu z " i ' nie obalisz bo takowy nie istnieje. Apostrofy są szybsze, a interpreter nie zamienia podwójnych na pojedyńcze ponieważ mają one inne zastosowanie i do czego innego służą. A niestety maszyna nie domyśli się o co chodziło człowiekowi.

Jakby interpreter pozamieniał to coś by mogło nie działać...

Podobnie jest z nawiasami i kropkami.... i innymi...

[optymalizator]

Apostrofy są szybsze

Same apostrofy są szybsze ('str' jest szybsze niż "str").

Ale jak się używa "str $zmienna" zamiast 'str ' . $zmienna, to nie trzeba złączać stringów, przez co skrypt działa o ten ułamek procenta szybciej.

[slawek22]

Akurat mitu z " i ' nie obalisz bo takowy nie istnieje. Apostrofy są szybsze, a interpreter nie zamienia podwójnych na pojedyńcze ponieważ mają one inne zastosowanie i do czego innego służą. A niestety maszyna nie domyśli się o co chodziło człowiekowi.

Ok nie wgłębiałem się w szczegóły ale PHP przed wykonaniem kodu dokonuje jego kompilacji do kodu pośredniego. Jeśli pewien rodzaj cudzysłowu faktycznie byłby szybszy to interpreter po prostu przeparsowałby łańcuchy, zmieniając np. "$a CCC $b" na $a.' CCC'... albo wygenerował szybszy kod pośredni.

Kompilator akurat w tym wypadku może zoptymalizować kod... bo z łańcucha łatwo wyodrębnić zmienne. Jeśli kompilator nie może - może to zrobić cache kodu pośredniego czy enkoder.

To są standardowe, proste optymalizacje które są wykonywane od lat np. przez kompilatory C (dajmy na to przeniesienie deklaracji zmiennej poza pętle).

Akurat mitu z " i ' nie obalisz bo takowy nie istnieje

Apostrofy są szybsze

Same apostrofy są szybsze

Wszystko na ten temat, właśnie członek zespołu PHP stwierdził, że rodzaj cudzysłowu nie ma znaczenia - a zaraz pod spodem 2 komentarze "który jest szybszy"

[Tomahawk]

Ok nie wgłębiałem się w szczegóły ale PHP przed wykonaniem kodu dokonuje jego kompilacji do kodu pośredniego. Jeśli pewien rodzaj cudzysłowu faktycznie byłby szybszy to interpreter po prostu przeparsowałby łańcuchy, zmieniając np. "$a CCC $b" na $a.' CCC'... albo wygenerował szybszy kod pośredni.

Ale zrozum że nie może zmienić " na ' bo to są zupełnie 2 różne elementy składni i mają różne zastosowanie

Równie dobrze mógłby cały kod zamienić na spacje i wtedy byłoby bardzo szybko...

[pawloski]

Wszystko na ten temat, właśnie członek zespołu PHP stwierdził, że rodzaj cudzysłowu nie ma znaczenia - a zaraz pod spodem 2 komentarze "który jest szybszy"

jeżeli '' działają inaczej niż "", to jedne z nich muszą być szybsze a drugie wolniejsze

dla prostych ciągów bez żadnych ./$ rzeczywiście '' są minimalnie szybsze

a dla mnie każda mikrooptymalizacja jest ważna, bo na tanim hostingu mam 550 domen

[slawek22]

Ale zrozum że nie może zmienić " na ' bo to są zupełnie 2 różne elementy składni i mają różne zastosowanie

Na prawdę nie potrafisz sobie wyobrazić kodu, który zamienia "XXX {$a} XXX" na ('XXX '.$a.' XXX') przecież to jest proste jak drut. Wystarczy znaleźć pozycje, gdzie zaczynają się zmienne. Możesz sobie nawet sam napisać taki skrypt który w ten sposób "zoptymalizuje" znaczy "rozpieprza" kod

a dla mnie każda mikrooptymalizacja jest ważna, bo na tanim hostingu mam 550 domen

Tylko, weź pod uwagę, że nawet przy takiej ilości domen zaoszczędzony czas pozwoli prawdopodobnie na jedno użycie systemu szablonów albo jedno wykonanie prostej kwerendy SQL.

Optymalizować trzeba tak, żeby po optymalizacji skrypt działał szybciej

[pawloski]

pozwoli prawdopodobnie na jedno użycie systemu szablonów

szablony wczytuję przez apc_fetch(), więc raczej nie jedno a tysiąc

jak się nie uda to jedynie wtedy file_get_contents() i apc_store()