PHP: půvab optimalizace rychlosti

Jezi se mi chlupy vsude kam jenom jde.

Delas (si) s pomerne zabavne a tvurci cinnosti (programovani; a obcas teda), pomerne nudnou cinnost (optimalizace kvuli nejakym obskurnostem v jazyce). Dyk tohle by, hergot, mela byt starost toho predzvykavce a optimalizera pro kompiler (preprocesor optimalizuje kod k prekladu?).

Tohle neni o PHP, neni to o ‚citelnosti‘ ternarniho operatoru. Je to proste zbytecne reseni zbytecneho problemu.

(Priste budu psat s nabodenicky. Mozna. Slibuju.)

#1 Solvino, Nechapu o jakem puvabu mluvis. PHP je jen webovy programovani, pokud se z nej odstrani i technicky problemy, tak tam nic nezbude (algoritmicky tam typicky zadny nejsou, webovy programator nemusi znat ani quicksort). Nutnost znalosti mnoha techickych zalezitosti (ruzny formaty a jazyky, vyjimky implementaci), je asi to jediny, co bych tady oznacil za slozity. To, ze se kod optimalizuje, neni moc prekvapujici.

Jinak v kompilovanych jazycich se taky ?: chova semtam jinak a nepouziva narozdil od ifu cache procesoru.

#1 Solvino, Příklad na nevhodnou referenci: ve funkci test() použijeme referenci, a to proto, že v C++ by použití pointeru dramaticky zrychlilo běh (vlastně nepoužít pointer by byla ostuda):

function test(&$a)
{
   $x = strlen($a);
}

// dlouhý řetězec
$s = str_repeat(' ', 1e6);

for ($i=0; $i<1000; $i++) test($s);

Cyklus trvá řádově sekundy. S dobrou znalostí PHP ale vím, že jsem udělal blbost a referenci odstraním:

function test($a)
{
   $x = strlen($a);
}

Cyklus teď trvá řádově milisekundy. To je rozdíl jak prase. Ale, mohl mi preprocesor pomoci? Nemohl! Protože blbost jsem udělal já a on ji musel respektovat.

Příklad na ternár:

$s = str_repeat(' ', 1e6);

// 1. cyklus
for ($i=0; $i<1000; $i++)
    $s2 = true ? $s : null;

// 2. cyklus
for ($i=0; $i<1000; $i++)
    if (true) $s2 = $s; else $s2 = null;

Zatímco první cyklus trvá řádově sekundy druhý jen mikrosekundy (sic!).

Ale není to o čitelnosti ternárního operátoru. Pravděpodobně jsi článek nepochopil.

#2 Me jako Molitane, No to co si oznacil za slozity musis znat u vsech programovacich jazyku. O potreby znalosti/neznalosti zakladnich algoritmickych poucek se snad ani nema cenu bavit (minimum je vedet, ze neco takovyho je a popr. se umet podivat na reseni).
k veci je az ten posledni odstavec – tvrdim, ze je spatne pokud se pri buseni kodu musis ohlizet na implemetace ‚reference countingu‘ ifu, nebo ternarniho operatoru.

#3 Davide Grudle, No pises celkem srozumitelne, takze clanek sem snad pochopil – ta poznamka o citelnosti byla inspirovana …ve vynechání (zdánlivě) zrychlujících… (ano, velmi volne inspirovana, je rano, pri konci uz sem jenom prelitaval text, vylozil jsem si to jako, ze se ti ternarni operator spatne cte).

Diky, ze si uvedl ten priklad s tim souborem. Pokud nedokaze proces kompilace SAM prelozit tvuj zdrojak tak aby fungoval tou druhou, rychlejsi, metodou (a zaroven obe metody jsou ekvivalentni, jedna se jenom o jinou syntax), tak je neco spatne. Bez ohledu na jazyk.

(Klate! Opet jsem zapomel diakritiku. Za odmenu jdu spat.)

#4 Solvino, Reagoval jsem na ten puvodni prispevek. Bez ukazek a tak.

Propooh! Ten druhy priklad by se mel SAMOZREJME bez reci prelozit na tu vyhodnejsi podobu.

Ten prvni je zapeklitejsi a tam bych na optimalizaci nesazel. Nicmene opet. Co kdyz tam budes pracovat s objektem (zkus si predstavit, ze String je OPRAVDU objekt a ne nejaky skalar). A ze tam budes delat neco opravdoveho – upravovat, volat metody a tak.

A navic se mi furt nezda, ze by takhle ustreny zlomky sekund mely nejaky smysl. Bottlenecky byvaj jinde. A PHP by na real-time nenasadil snad nikdo.

#4 Solvino, > No to co si oznacil za slozity musis znat u vsech programovacich jazyku.

Jen bych chtel rict, ze to, co jsem podle tebe oznacil za slozity, jsi ty predtim oznacil za nudny (ja jen, aby bylo videt, o cem je rec). Mimoto ja jsem to neoznacil za obecne za slozity. Jen za slozity v ramci webovyho programovani (a tvorici tak jeho hlavni pracovni napln). Obecne je to celkem jednoduchy.

na implemetace ‚reference countingu‘ ifu, nebo ternarniho operatoru.

Aha, a ja si vzdycky myslel, ze programator musi vedet, jake vlastnosti ma ta konkretni implementace kompileru, co je uvnitr procesoru, co jsou SSE instrukce, … Jenze jde o to, ze webovy programovani neni ani moc o programovani. Je to reseni dvou otazek: „Jak si mam rozvrhnout tech 200 kB rutinniho PHP kodu do .php souboru?“ a „Proc mi to v tom MSIE nefunguje?“

#5 Solvino, bylo by fajn, kdyby se ten druhý příklad realizoval přes reference counting, ale v tuto chvíli je důležité vědět, že se tak neděje. Nejsem s to odhadnout, jak by byla taková úprava kompileru náročná – totiž místo proměnné se tam přiřazuje výraz – a přes ten se logicky -rc- nedostane. Možná to je jednoduché jen zdánlivě.

ad první příklad: tady je zbytečné ptát se, co když. Jde totiž o chybnou optimalizaci programátora způsobenou neznalostí (resp. přenášením zvyklostí z jiných jazyků). Reference se mají používat, jen pokud chci vracet hodnotu, byť třeba objekt. (samozřejmě, v PHP4 se reference používaly i kvůli pofiderní nepodpoře objektů, ale to je jiné téma)

#6 Me jako Molitane, je pěkné, že jsi v poslední větě popsal své schopnosti webového programátora, ale příště více zdůrazni, že mluvíš pouze za sebe 🙂

#7 Davide Grudle, Myslim, ze mych 7 let praxe, behem ktere jsem ve webovem programovani zadny algoritmicky zajimavy problem nepotkal, vypovida neco nejenom o mne, ale i o samotnem webovem programovani. Zajimave je, ze kdyz jsem ted mel naprogramovat neco offline, tak se tam hned objevila nejaka nelinearni optimalizace.

#8 Me jako Molitane, vypovídá to pouze o tobě. Já je potkávám docela často. A ještě víc mě baví navrhování celých systémů, hledání elegantních řešení.

to DGX: jen takova technicka, muzes mi rict jak si na to prisel? Zajimala by me situace, kdy te tohle trklo.

//hrozné:
$a = isset($x) ? $x : false;

//prišiel čas venovať sa:
$a = $x or false

//ruby :)

Jen bych dodal, že jakmile se předává pole nebo objekt (což jsou nejčastěji obsáhlé proměné), tak zpět na stromy – reference opravdu urychlí provádění skriptu, dle mých testů cca dvakrát.

#3 Davide Grudle, Pri všetkej úcte, dovoľ aby som sa zasmial. Toto je definitívne vykonštruovaný prípad. Kedy si potreboval naposledy tisíckrát prehadzovať nejaký megový string?

Optimalizácie reálnych aplikácii sa točia okolo úplne iných vecí. Ak však mi napíšeš reálnu aplikáciu, kde ti toto konkrétne pomohlo, tak ten môj smiech ruším.

Na druhej strane však musím uznať, že odsúdenie nadmerného a zbytočného používania referencí schvaľujem na 100%.

#12 milo, tak schválně si vyzkoušej příklady #3 David Grudl, jen zaměň $s = $_SERVER;. Zjistíš, že realita je jiná.

#10 error414, jsem si ověřoval, jestli při ternárním operátoru se využije r. c., no a napadlo mě o tom napsat článek ;)

#11 Ivane, dobrá – jak se v Ruby vyhodnotí 0 ? 1 : 0 ?

No abych to uzavrel (jsem o trosku min unavenej). Nechci snizovat to co dgx nasel, je to zajimava vec, ktera muze urychlit provadeni skriptiku o tom zadna. Jenom mi to prijde jako: To muselo dat prace a pritom takova blbost.

Chlupy mi vstavaj z toho, ze bych mel pri prgovani myslet jeste tady nato (nebo na zoufalou neefiktivitu switch/case v jave).

Co budes delat az vydaj dalsi verzi PHP, ktera bude mit jinou zajimavost. Refaktorovat? Tohle nejsou trivialni zmeny v kodu.
Jak se k tomu chova PHP5? Tam uz se predava reference, ne?
Jinak se klonim spis k Molitanovu videni sveta: netvrdim, ze neni web programator, ktery se snazi optimalizovat, ale krome sebe (a to jenom v zoufalych pripadech, kdy uz to bylo neunosne) jsem za tu dobu co jsem to delal/delam nikoho nepotkal.
#6 M jako Molitan Az na par pojmu nudny/slozity mam pocit, ze mluvime o tom samem.

#13 johno, Johno, že zrovna ty se tak ptáš. Vem si svůj (skvělý) ngram.php a vygeneruj slovní bigramy na půlmegovém vstupu. Metoda addNGram() se zavolá 80.000×, operace trvá 32 minut. S velmi droboučkou minioptimalizací ji srazím na 3 sekundy.

Samozřejmě, můžeš se tomu smát, protože kdo kdy viděl volat nějakou funkci 80.000×, že? 🙂 Taková divoká konstrukce, no fuj…

#15 Solvino, Solvino, nejprve prosím pochop, že nejde o zajímavost (s těma se vážně nepárám), ale o klíčovou vlastnost jazyka od dob jeho počátku na bázi Zend jádra. A teď zpětně – vážně ti přijde tak šílené, že jsem tuto vlastnost popsal? A zmínil, jak zrychluje provádění skriptů a snižuje (dost omezené) nároky na paměť? A nakonec naznačil, jak jí neházet klacky pod nohy? Že je lépe neoptimalitovat, než blbě optimalizovat? Vážně tím dělám z programování nudnou činnost?

#16 Davide Grudle, Stále ještě žijí lidé, kteří mají chuť si pamatovat, jak dělat věci efektivně. Díky, Davide.

Jenomže tito lidé, jako jsem třeba já, se nemohou zovat rutinními (PHP) programátory a tedy nám nečiní problém poupravit trochu svůj zvyk směrem k efektivnějšímu kódu.

Mně Tvoje glosa užitečná přijde habaděj. Tak. Nelze se divit, že nás pokládají za jednu a tutéž osobu, když Ti na La Trine nechávám výhradně takto úlisné komentáře. :o)

#16 Davide Grudle, jak si zminil to cislo 80.000 tak v tom bych nevidel takovy problem.

Videl jsem nekolik kodu

$i = 0;
while($i < 800){
   $trida->uloz($i++, date("Y/m/d"));
}

to se pak divite kolikrat se muze volat nejaka funkce.

#14 Davide Grudle,

0 ? 1 : 0

$a = (int) !$x;

#16 Davide Grudle, Ok, tak smiech dočasne ruším.

Nechápem ako si to skresal na 3 sekundy. Pozerám na všetky referencie, čo tam používam a ani jednu neviem dať poriadne preč. Asi mi mäkne mozog.

Čo sa však môjho komentára o zbytočných optimalizáciach týka, tak stále tvrdím, že v drvivej väčšine prípadov takéto veci nemajú zmysel. Viď večný flame o jednoduchých a dvojitých úvodzovkách pri reťazcoch.

Dôležité je teda vedieť rozlišovať kedy je takéto niečo dôležité a kedy nie.

V tomto momente púštam profiler na Ngram.php

#20 johno, Jde jen o využítí určité pevně dané vlastnosti jazyka, čistě v duchu tohoto článku. Uprav si metodu takto:

function addNGram($ngram) {
    $arr = &$this->table;
    $lastToken = array_pop($ngram);
    foreach($ngram as $token) {
//    if(!array_key_exists($token, $arr)) {
//      $arr[$token] = array();
//    }
      $arr = &$arr[$token];
    }
//  if(!array_key_exists($lastToken, $arr)) {
    if(!isset($arr[$lastToken])) {
        $arr[$lastToken] = 0;
    }
    $arr[$lastToken]++;
}

Dôležité je teda vedieť rozlišovať kedy je takéto niečo dôležité a kedy nie.

Zrovna tato optimalizace krásně demonstruje, že jsem nic „nekomplikoval“ – naopak – odstranil jsem několik řádků. Toť oč tu běží. Pokud vím, jak fungují určité rysy jazyka, tak prostě s nimi žiji v symbióze a tím pasivně optimalizuji. A to plošně, ne jen ve vybraných funkcích, nebo podle doporučení profilera (to už pak je aktivní optimalizace).

Viď večný flame o jednoduchých a dvojitých úvodzovkách pri reťazcoch.

Ale ono je to stále o znalostech. Protože vím, že tam naprosto žádný rozdíl není, tak se rozhoduju podle pohodlí, přehlednosti atd. Ale kdyby tam byl rozdíl, tak budu mít tendenci používat „rychlejší“ uvozovky. Samozřejmě tendence by byla velmi slabá, odpovídající tomu zrychlení o 0.0001 ‰ 🙂

#9 Davide Grudle,

vypovídá to pouze o tobě. Já [vymysleni netrivialnich algoritmu] potkávám docela často.

Tuhle vyhradu oproti webovymu programovani nediskutuju poprvy a zajimave je, ze i kdyz vsichni pokazde tvrdi opak, tak nikdo nerekne protipriklad.

A ještě víc mě baví navrhování celých systémů, hledání elegantních řešení.

Souhlasim, vsak sem taky rikal, ze webovy programator resi „Jak si mam rozvrhnout tech 200 kB rutinniho PHP kodu do .php souboru?“

#21 Davide Grudle,

Ale kdyby tam byl rozdíl, tak budu mít tendenci používat „rychlejší“ uvozovky.

Ale on tam rozdíl je! Single quoted řetězec se neprohledává na záměnu proměnných („ahoj $name“);

<?php
$time=microtime(true);
$str='';
for($i=0; $i<1e6; $i++)
	$str='Tohle je velmi, ale opravdu velmi dlouhý řetězec, který má demonstrovat, jaký je rozdíl mezi single a double quotes.';
echo (microtime(true)-$time).'<br>';
$time=microtime(true);
$str="";
for($i=0; $i<1e6; $i++)
	$str="Tohle je velmi, ale opravdu velmi dlouhý řetězec, který má demonstrovat, jaký je rozdíl mezi single a double quotes.";
echo (microtime(true)-$time).'<br>';
?>

rozdíl je cca 10%, u mě na mašině průměrně 1,04 a 1,19s.

#23 The Zero, mýlíš se (a potvrzuješ si omyl chybným měřením).

Každý řetězec se v PHP musí zpracovat znak po znaku, ať je v uvozovkách takových či makových. On se totiž znak po znaku musí přechroustat celý zdroják – tím je to dané.

Analýza kódu je nesmírně blesková záležitost. Při průchodu řetězcem uzavřeným jednoduchými uvozovkami se každý znak testuje na metaznak, což je ' a \, v případě řetězce ve dvojitých uvozovkách je to " \ { $. Tento rozdíl je neměřitelný!

Poté se vygeneruje bytecode, přeložená verze, která se vykonává. Ať je řetězec zapsán v jakýchkoliv uvozovkách, vznikne totožný bytecode. Tedy rychlost provádění se nemůže lišit.

Rozdíl, byť neměřitelný, vzniká pouze při analýze, což zrovna tvůj benchmark vůbec nezjišťuje.

Zkus měření ještě jednou.

No ono používat reference namisto přiřazení je tak trochu divne ;) To jsou pokadé dvě uplně jiné věci pokud vim a jen ten kdo neumi programovat to tak používá ;)

#19 llooku, no, Ruby vyhodnotí 0 ? 1:0 jako 1, ne?

#3 Davide Grudle, Nechtelo se mi tomu rozdilu verit, rikal jsem si, ze bude problem spis v te podmince nez v operatoru, ale skutecne je if() mnohem rychlejsi i tehdy, kdyz se ta podminka meni. Takze v tomto pripade mas urcite pravdu a ja si urcite budu pamatovat, ze v teto situaci je vyhodnejsi pouzivat otaznik.

Akorat ze v realnych aplikacich takovy pripad nenajdu a zpomaleni v radu setin mikrosekundy, ktere mi vyvola pouziti ? misto if, se uplne ztrati ve vsech tech regexpech a pripojenich k databazi.

#11 Ivane, Nastav si nekdy v PHP, at ti hlasi i E_NOTICE a budes zirat, jak je ten „hezky“ druhy tvar najednou nevhodny.

to je krasne, jen ten ktery neumi programovat nepise podle me.

Ono se dloho diskutuje co je dobre a co spatne a ted DGX borti zdi.

ten muj predchozi prispevek byl pro 25

Dobre ze si to uverejnil. Určite to niekedy vo svojich kodoch zohladnim :)

#22 Me jako Molitane,

Tuhle vyhradu oproti webovymu programovani nediskutuju poprvy a zajimave je, ze i kdyz vsichni pokazde tvrdi opak, tak nikdo nerekne protipriklad.

Chceš algoritmicky zajímavý problém? Máš v databázi tabulku TV pořadů seřazenou podle času začátku, u každé položky máš název pořadu, délku, popis atd. a taky TV stanici. Úkolem je výstup zobrazit v tabulce, kde v každém sloupci je jedna stanice a pořady jsou ve vertikálně slučovaných buňkách tak, aby byla ve výsledku zobrazena časová souslednost a návaznost – tak jako je to k vidění na http://www.televize.cz/…am/vypis.php

Problémem z podobného ranku je zobrazit týdenní kalendář coby tabulku s denními sloupci a půlhodinovými řádky (se zvýrazněnou celou hodinou) a v nich zadané eventy (schůzky apod.) natažené přesně podle jejich délky (s přesností 15min.), přičemž jednotlivé eventy nejsou exkluzivní, tj. v jednom okamžiku můžou probíhat i dva a více současně.

Dělal jsem obojí (první v PHP, druhé v JS) a jestli tohle nejsou algoritmicky zajímavé problémy, tak už nevím… ;)

DGX, díky! 🙂

Určitě se tento poznatek hodí, a nemyslím, že by to byla jen „zajímavost“.

#24 Davide Grudle, Eh, no jenze on se podle Sary je to s bytecodem trosku jinak… https://web.archive.org/…80/index.php?…

Pro neanglicany: ‚ahoj lidi, jak se vede‘ je jeden retezec, „ahoj lidi, jak se vede“ je jeden retezec ‚ahoj‘ + 8 pripojeni dalsich retezcu…

#33 Mordae, Není. To se týká pouze případů, kdy se v řetězci používají proměnné (nebo u HEREDOC syntaxe). Tedy „ahoj lidi, jak se vede“ je jeden řetězec, nikoliv osm připojení.

Ahoj,

rozdelil bych to na dve veci:

• je dobre vedet, ze jazyk ve kterem obcas delam ma tuhle feature/bug. Budu na to myslet a nekde dodelam komentar „All hail the hypno-dgx!“
• nechci delat v jazyku, ktery me nedokaze odstinit od takovych trivialit a nuti me resit veci za autory jazyka. (Zvlast hnusny je to v pripade PHP, ktere se chlubi tim, jak je pristupne pro zacinajici/prilezitostne programatory. Hm.)

Mimochodem nazyvej to potmesile chovani jak chces, klidne i klicovou vlastnosti jazyka podle me to je zajimavost a nedivil bych se, kdyby to v dalsich verzi opravili.

Ja pri programovani nehci optimalizovat timhle smerem! Ja chci psat slusny kod, bez prasaren, optimalizovany na urovni logicke vrstvy a at si s tim prekladac poradi jak nejlip umi.

#31 pixy,

Dělal jsem obojí (první v PHP, druhé v JS) a jestli tohle nejsou algoritmicky zajímavé problémy, tak už nevím… ;)

Mas pravdu, tohle je skutecne neco, co se trochu da nazvat slovem algoritmus. Jen jsem dost skeptik, co se tyce cetnosti takovych problemu.

#36 Me jako Molitane, Myslism, ze je to skutecne Tvuj „problem“. Pokud zacnes psat v PHP nejaky trochu sofistikovanejsi framework, zacnes resit svuj vlastni template engine, vhodny zpusob cachovani, efektivnejsi spravu kontextu, obecnou persistentni vrstu, atd. atd. tak nejenze celkem jiste prijde na radu otazka optimalizace, ale muzu Ti zarucit, pokud to ma k necemu bejt, ze na algoritmicke problemy narazis, a ne jednou.
Pokud to pro tebe neni algoritmicky problem, jednoduse Ti neverim, protoze napriklad jen okolo persistence vzniklo uz mraky navrhovych vzoru, projektu na kterych pracuji tymy vedcu (java / hybernate)… a porad se hledaji nove/lepsi zpusoby.
Webove programovani davno neni o tom soupnout do statiky novinky a udelat k nim primitivni admin.
Btw. ja programuju 9 let a pripojuji se k tem, kteri algoritmicke problemy potkaly ;).