Autor Zpráva
Jonweb
Profil *
Dobrý den,

našel jsem zde velice zajímavou diskusi Optimalizace PHP kódu s různými způsoby zrychlení kódu.

Znáte nějaké další způsoby? Které považujete za nejužitečnější?

Děkuji.
Alphard
Profil
A četl jste tu diskusi celou? Řada „rad“ je rozporována, zbytek zanedbatelný. Obecně jsou pomalé IO operace, takže ty maximálně omezit. Často jsou brzdou blbě navržené databázové dotazy.
Změnou syntaxe zrychlení nedosáhnete, jde hlavně o algoritmizaci a tam nelze radit obecně.
Joker
Profil
Jonweb:
Které považujete za nejužitečnější?
- V první řadě se naučit pořádně programovat.
- Potom se případně naučit mechanismy, jak zhruba různé PHP konstrukce fungují a naučit se rozpoznávat, kde se nejspíš spotřebuje hodně času.
- Následně se naučit jak PHP vnitřně funguje.
- Pak možná řešit kraviny typu kolik času spotřebuje operátor spojování řetězců.

Zkušenost mj. z tohoto fóra říká, že ten poslední bod je doménou lidí schopných se hodiny hádat jestli apostrofy jsou o 0,0000000000000000001s rychlejší než uvozovky, když kvůli hloupému návrhu skriptu ztrácejí 2 sekundy na jeden běh.

Které považujete za nejužitečnější?
Ty uvedené jsou vesměs neužitečné kraviny. Odkazovaný web už neexistuje, tak jenom rychle k těm uvedeným:
ad 3) „Používejte více parametrů echo místo spojování řetězců“
Zkusil jsem to změřit a vyšlo mi to přesně naopak.
Pro zajímavost, rozdíl byl závratných 0,0000007s na jedno volání. Čili pokud v kódu máte 100x echo, udělá to celých 0,00007s na celé zpracování skriptu.

ad 7) „require_once je časově náročný.“
ad 8) „Používejte plné cesty v include a require“
Neumím si představit situaci, ve které by časová náročnost require_once hrála nějakou roli.
Pokud by skript vkládal tolik souborů aby se to projevilo, bude problém už v tom, že vkládá tolik souborů.

ad 13) „Je lepší používat select, než vícenásobný if/elseif“
Sice je lepší používat select, ale důvodem je přehlednější kód. S výkonem to nemá nic společného.
Zkusil jsem benchmark, vypadá to, že většinou (ne vždycky) je rychlejší if/elseif, ale rozdíl prakticky není měřitelný.

ad 14) „Potlačování chybových hlášek zavináčem je velmi pomalé“
Potlačovat chybové hlášky zavináčem není dobré z principu.
Jinak totéž jako require_once: Neumím si představit, že by to nějaký skript použil tak často, aby to udělalo nějaký rozdíl.

ad 16) „Uzavřete databázové spojení jakmile není potřeba“
To může být dobrý nápad, ovšem běh skriptu to zpomalí (uzavřít spojení bude pomalejší než nedělat nic).
Jinak u starého MySQL rozšíření PHP manuál říká, že uzavírat spojení je zbytečné.
U nových rozšíření pro MySQL už tam ta věta není a doporučuje se připojení spíš uzavírat, i když to není potřeba (na konci skriptu se uzavře stejně).

ad 17) „$row[’id’] je 7x rychlejší než $row[id]“
Tohle jsem nepochopil, použití $row[id] ve smyslu $row["id"] je v první řadě chyba (je to použití nedefinované konstanty, byť PHP nedefinované konstanty automaticky převádí na řetězec).
Jonweb
Profil *
Děkuji za odpovědi.

Zajímalo by mě, jaké postupy má smysl používat. Třeba TOP 5. Aktuální odkaz na článek je http://www.chazzuka.com/63-best-practice-to-optimize-php-code-performances-58/. Nebo existují ještě nějaké lepší? Nechci používat to co nemá smysl, jak píšete.

Kolega tvrdí, že stačí nainstalovat Eaccelerator a skripty se automaticky zrychlí. Stačí to?
juriad
Profil
Většina z toho nemá smysl; obecně si myslím, že takové seznamy „best practice“ spíše škodí, zvlášť lidem, kteří nejsou dostatečně zkušení.
Programuj tak, jak je ti to přirozené, nemysli na to, jaký konstrukt máš použít, protože někde jsi četl, že je o chlup rychlejší.
Zjistíš-li, že je skript pomalý, změř si nějakým profilerem, kde se tráví při vykonáváni nejvíce času.
To místo se potom můžeš snažit zrychlit; nejčastěji tak, že použiješ lepší algoritmus (ať už eliminaci smyček, vyhození zbytečného řazení či náhradu regulárních výrazů za řetězcové operace).
Pokud to nepomůže, někoho se zeptej na nezávislý názor (klidně třeba tady na Diskusi), téměř vždy existuje elegantnější řešení.
Pokud ani to nepomůže, můžeš začít uvažovat magii a řídit se těmi typy.

Optimalizovat tedy, až máš změřeno, že je skript pomalý, a jen části, které jsou prokazatelně pomalé.
Joker
Profil
Jonweb:
Jak píše juriad; Nejlepší je naučit se „správně“ programovat a psát kód tak, aby byl přehledný a snadno udržovatelný.

A teprve když je reálně pomalý, začít u toho konkrétního kódu pátrat proč je pomalý a podle toho se pak zařídit.
Koneckonců, dneska když je aplikace pomalá, často je nejjednodušší a nejlevnější řešení pořídit silnější hardware.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0