PHP: půvab optimalizace rychlosti

K čemu slouží ternární operátor, jistě vysvětlovat nemusím. Víte, že tyto dvě operace jsou ekvivalentní:

$a = $cond ? $x : false;

if ($cond) $a = $x; else $a = false;

Co ovšem možná nevíte, tak že ta první může být více než tisíckrát pomalejší. Stačí, aby proměnná $x obsahovala delší řetězec nebo pole.

Jak je to možné?

Reference counting

Jedna z úžasných vlastností jádra PHP 4 se nazývá Reference counting (pozor, nemá nic společného s klasickými referencemi). Díky ní nedochází ke kopírování dat okamžitě při přiřazení $a=$b, ale až je to potřeba, obvykle při změně jedné z proměnných. Fígl je v tom, že docela často hodnoty proměnných jen čteme, a tedy k jejich změně vůbec nedochází. Pak reference counting ušetří paměť a zvýší rychlost provádění skriptu.

Zkoumat jeho chování můžete funkcí debug_zval_dump (raději však xdebug_debug_zval) a sledováním hodnoty refcount. Doporučuji si s ní zaexperimentovat.

Klasické přiřazení $a = $b je tedy extrémně rychlé. A může být mnohem rychlejší, než vytvoření reference $a = &$b (podrobně v článku černá magie optimalizace). Pokud používáte reference namísto přiřazení kvůli rychlosti, dosahujete opačného efektu!

Tento kód je možné optimalizovat…

foreach ($arr => $val)
  if ($this->internalParameters['id'] == $val) ...

…pomocí klasické reference…

$p = & $this->internalParameters['id'];

foreach ($arr => $val)
  if ($p == $val) ...

…ale lepší bývá přístup bez reference:

$p = $this->internalParameters['id'];
...

A tím se dostáváme zpátky k problému s ternárním operátorem. Ten totiž, narozdíl od příkladu s konstrukcí if - else, kopíruje data ihned. Což značně zpomaluje provádění. Ale abych byl korektní – v případě, že budete obsah proměnné v dalších krocích měnit, tak stejně ke zkopírování paměťového bloku dojít musí, a pak nelze hovořit o zpomalení.

Je dobré pochopit chování reference counting a využívat ho. Pokud mezi proměnnými předáváte větší řetězce či pole, procházíte stromy a podobně, může dramaticky zrychlit provádění aplikace. Zajímavé je, že optimalizace pro něj spočívá ve vynechání (zdánlivě) zrychlujících konstrukcí a v psaní prostého kódu.

Komentáře

Solvina #1

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

před 18 lety | reagoval [2] M jako Molitan [3] David Grudl
M jako Molitan #2

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

před 18 lety | reagoval [4] Solvina
David Grudl #3
#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.
před 18 lety | reagoval [4] Solvina [13] johno [14] David Grudl [27] pepak
Solvina #4

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

před 18 lety | reagoval [5] Solvina [6] M jako Molitan
Solvina #5

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

před 18 lety | reagoval [7] David Grudl
M jako Molitan #6

#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?“

před 18 lety | reagoval [7] David Grudl [15] Solvina
David Grudl #7

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

před 18 lety | reagoval [8] M jako Molitan
M jako Molitan #8

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

před 18 lety | reagoval [9] David Grudl
David Grudl #9

#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í.

před 18 lety | reagoval [22] M jako Molitan
error414 #10

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

před 18 lety | reagoval [14] David Grudl

Ivan #11

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

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

//ruby :)

před 18 lety | reagoval [14] David Grudl [27] pepak

mila #12

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.

před 18 lety | reagoval [14] David Grudl
johno #13

#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%.

před 18 lety | reagoval [16] David Grudl
David Grudl #14

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

před 18 lety | reagoval [19] llook
Solvina #15

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.

před 18 lety | reagoval [16] David Grudl
David Grudl #16

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

před 18 lety | reagoval [17] Dero [18] error414 [20] johno
Dero #17

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

před 18 lety
error414 #18
#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.
před 18 lety
llook #19

#14 Davide Grudle,

0 ? 1 : 0

$a = (int) !$x;

před 18 lety | reagoval [26] David Grudl
johno #20

#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

před 18 lety | reagoval [21] David Grudl
David Grudl #21
#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 ‰ ?
před 18 lety | reagoval [23] The Zero
M jako Molitan #22

#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?“

před 18 lety | reagoval [31] pixy

The Zero #23

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

před 18 lety | reagoval [24] David Grudl

David Grudl #24

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

před 18 lety | reagoval [33] Mordae
Petr #25

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á ;)

před 18 lety
David Grudl #26

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

před 18 lety
pepak #27

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

před 18 lety
error414 #28

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.

před 18 lety
error414 #29

ten muj predchozi prispevek byl pro 25

před 18 lety
hvge #30

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

před 18 lety
pixy #31

#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… ;)

před 18 lety | reagoval [36] M jako Molitan
Tomik #32

DGX, díky! ?

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

před 18 lety
Mordae #33

#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…

před 18 lety | reagoval [34] David Grudl
David Grudl #34

#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í.

před 18 lety
Solvina #35
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.
před 18 lety
M jako Molitan #36

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

před 18 lety | reagoval [37] radek
radek #37

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

před 17 lety

Tento článek byl uzavřen. Už není možné k němu přidávat komentáře.

PHP: půvab optimalizace rychlosti

Reference counting

Komentáře

Solvina #1

M jako Molitan #2

David Grudl #3

Solvina #4

Solvina #5

M jako Molitan #6

David Grudl #7

M jako Molitan #8

David Grudl #9

error414 #10

Ivan #11

mila #12

johno #13

David Grudl #14

Solvina #15

David Grudl #16

Dero #17

error414 #18

llook #19

johno #20

David Grudl #21

M jako Molitan #22

The Zero #23

David Grudl #24

Petr #25

David Grudl #26

pepak #27

error414 #28

error414 #29

hvge #30

pixy #31

Tomik #32

Mordae #33

David Grudl #34

Solvina #35

M jako Molitan #36

radek #37