Dotaz: Režie spojené s voláním funkce versus inline expression

[OldFrog {Ondra Nemecek}]

Zdravím,

v kódu často testuju, zda je proměnná nenulová, neprázdná apod. Udělal jsem si na to třídu se statickými metodami, např.:

class Validator {

	public static function notEmpty($mValue){
		if(!isset($mValue)){
			return false;
		} else if(is_null($mValue)){
			return false;
		} else if (is_integer($mValue)){
			return true;
		} else if (is_object($mValue)){
			return true;
		} else if(is_string($mValue)){
			return strlen($mValue) != 0;
		} else if(is_array($mValue)){
			return sizeof($mValue) > 0;
		}
	}
}

Tato metoda dost zpřehlednila kód. Bohužel se ale volá během requestu mnohokrát a to něco stojí. Pokud test implementuju jako normální funkci, je to jen nepatrně rychlejší. Pokud však tělo metody zapíšu do kódu rovnou jako výraz, je to mnohem rychlejší. Jednoduchý test volající validaci 1000x ukázal:

Checked 1000x via Validator method in 3.41 ms
Checked 1000x via inline expression in 0.19 ms

To mne vede myšlence, zda neexistuje v php něco jako makra v C? Tj. abych měl validační kód na jednom místě a přitom aby odpadla režije s voláním metody?

Díky za případné náměty!

Odpovědi

[OldFrog {Ondra Nemecek}]

PS: Používám PHP Version 5.3.8.

[Ladicek]

To mne vede myšlence, zda neexistuje v php něco jako makra v C?

Když bude nejhůř, můžeš na zdrojáky vždycky pustit cpp (nebo jakýkoli jiný preprocesor nebo makroprocesor nebo obecně šablonovací systém, whatever).

[OldFrog {Ondra Nemecek}]

Taky možnost - musel bych to zařadit do deploymentu. Jsem myslel jestli to nejde nějak transparentně.

[Josef Kufner]

Spíš se zamysli, jestli by nestačilo udělat néco jako:

if (!empty($mValue)) { ... }

nebo

if ($mValue !== null) { ... }

Jak vypadá ten kód okolo?

[OldFrog {Ondra Nemecek}]

Fce empty() je dobry pokus resit tyhle pripady, ale nelíbí se mi, protože integer 0 je podle ni prazdny. Neidentita s null (!== null) zase oznaci za neprazdny prazdny retezec. Jinymi slovy si nemuzu chovani te validace ovlivnit ani rozsirit. Navic ve tride Validator mam implementovane i jine validace nez validaci na neprazdnost.

Kdyby byl nejaky standardizovany preprocesor ktery je obecne rozsireny, pak by muj problem resil elegantne.

Nicmene beru vsechny pripominky - ten problem neni zasadni, spis hledam, jak to do budoucna koncepcne lepe resit.

[Josef Kufner]

Doporučuju hned na vstupu převést všechny prázdné hodnoty na NULL a ty ostatní nechat jako něco jiného. Pak ti stačí jeden rychlý test.

[OldFrog {Ondra Nemecek}]

Ano, to je asi nejlepší přístup pro skalární typy. Pokud jde ale třeba o pole, už se to komplikuje. Pole všude inicializuju jako prázdné pole a jako takové je považuju za empty. Pokud by bylo pole někdy NULL, musel bych ho podmíněně inicializovat a po inicializaci stejně dle potřeby zjišťovat, zda obsahuje prvky.

Tj. složené typy chápu jako empty pokud nemají žádný prvek (a řetězec je v tomto pojetí složený typ s prvkem znak) nebo jsou NULL, ostatní pokud jsou NULL. S tímto přístupem jsem zatím nanarazil a myslím, že je v zásadě správný.

Považuju současně za dobré mít kontroly na jednom místě - moje pojetí neprázdnosti je pak na onom místě zřetelně vyjádřené a platí pro celou aplikaci - stačí se podívat na onu metodu. Pokud bych pomíněně kontroloval přímo v kódu s ohledem na typ, zanese se užitečný kód balastem, který nesouvisí přímo s aplikační logikou a tím utrpí čitelnost.

Správné řešení je podle mne proto preprocesor (makra) nebo nějaký optimalizátor, který ta makra udělá přímo za běhu místo mě.

[Kit]

Považuju současně za dobré mít kontroly na jednom místě - moje pojetí neprázdnosti je pak na onom místě zřetelně vyjádřené a platí pro celou aplikaci - stačí se podívat na onu metodu. Pokud bych pomíněně kontroloval přímo v kódu s ohledem na typ, zanese se užitečný kód balastem, který nesouvisí přímo s aplikační logikou a tím utrpí čitelnost.

Kontrola přece patří k objektu, do kterého se daná hodnota ukládá. Dál se pracuje už jen s naplněnými objekty, resp. jejich gettery. Tím se hlavní kód zjednoduší na minimum a zpřehlední.

[OldFrog {Ondra Nemecek}]

Proč ne, ovšem na druhou stranu se tím kód zduplikuje (všechny kontroly např. na string se zduplikují v setterech). Oba přístupy jsou relevantní a musím mezi nimi volit. Navíc, někdy kontroluju i jiné veci než neprázdnost (jen ne tak často, ale mám je také ve třídě Validator). Čili shrnuto - ke kontrole nemusí docházet jen při get/set.

Ještě podotknu, že ne všechny hodnoty jsou zabaleny v objektu. To by bylo vystaráno. Měl bych třeba třídu String a ta by sama implementovala isEmpty.

[Kit]

Pokud z konstruktoru voláš setter, k duplicitě dojít nemusí. Často však samostatné settery nejsou potřebné a je možné celou záležitost svěřit konstruktoru.

Granularita tříd je samozřejmě na tvůrci, ale konkrétně třídu String bych vůbec nedělal. Vždycky je v řetězci nějaká hodnota, která má nějakou sémantiku a zaslouží si vlastní ošetření integrity vstupních dat.

[Josef Kufner]

Ono hlavně ty kontroly by mělo stačit udělat jen jednou někde na začátku, při vstupu dat do programu. Pak už je zbytečné je kontrolovat znovu a znovu.

String se obvykle ve skriptovacích jazycích řadí mezi skalární typy, hned vedle int.

Pole opravdu vyžadují jinou kontrolu, ale tam zas dopředu víš, že to je pole a podle toho tam můžeš namísto $x !== null napsat !empty($a).

Btw, ty dvě rovnítka tam nejsou omylem.

[OldFrog {Ondra Nemecek}]

Však já to všechno vim. Ale přepisovat to popsaným způsobem nechci.

[Kit]

"V kódu" zní dost obecně. Podle mne by takové testy neměly být ve statické třídě, ale jako součást konstruktoru/setteru. V tom případě se bude kontrolovat jen konkrétní datový typ a případné závislosti. Testování tím bude jednodušší a rychlejší.

[OldFrog {Ondra Nemecek}]

Třeba by pomohlo PHC (http://www.phpcompiler.org/)? Kdybych z Validatoru udělal php extension, možná by se pak volání metody zrychlilo na úrověň empty()? Nebo použít nějaký jiný nástroj, nějaký JIT optimalizátor? Máte někdo zkušenost?

Taky jsem našel CCPP (http://code.metala.org/p/ccpp/), kdyby se to použilo na kód a měl jsem zapnuté APC (http://php.net/manual/en/book.apc.php) - aby se preprocesor nemusel pouštět při každém requestu - to by taky mohlo pomoct.

Ten Validator je jediné uzké hrdlo (stráví se tam podle xdebug asi 25% času), zbytek je dost vyrovnaný. Celkově mi request trvá 50ms(obrázek)-300ms(html) (měřeno logováním na serveru), přičemž těch requestů je na stránku několik, takže zrychlení by nevadilo Mám tam html cache, která to řeší, ale tu nelze použít vždy.

Čili mne spíše zajímá, jak zrychlit to volání statické metody, protože jsem se původně domníval, že je stejně rychlé jako inline expression...

[Kit]

Ten validátor je zbytečně komplexní. Některé řetězce například musí zůstat prázdné (např. antispamový $_GET[nick] ve skrytém poli), jiné mohou být prázdné (např. $_GET[state] u neamerického státu) a jiné je třeba nutné před uložením do objektu otestovat na přítomnost v databázi. Nejsou to řetězce, ale nick, state a např. username. A každý z nich se testuje jinak.

[Josef Kufner]

A někdy je navíc vhodné rozlišovat prázdný string od neinicializovaného stringu. Tedy "" vs. null.

[OldFrog {Ondra Nemecek}]

Vážení!

Validator ani jeho metoda notEmpty není sama o sobě tématem dotazu. Tématem je, proč ten kód běží rychle inline a pomalu jako metoda a co s tím.

Čili děkuju za návrhy čím metodu notEmpty nahradit, bral bych je, pokud by se jimi dal jednoduchým refaktoringem Validator při zachování stávajícího designu nahradit. To však nejde, ani nejdadějnější metoda empty() nevyhovuje, musel bych - jak správně říkáte - brát v úvahu typ proměnných atd... a to nechci.

Potřebuju-li tedy rozlišit "" vs. NULL tak to samosebou rozlišuju atd... nicméně místo notEmpty si teď přestavte libovolnou statickou metodu a pak případně pokračujte v diskurzu

[Josef Kufner]

Důvod je prostý: Volání metody má nějakou ne zrovna zanedbatelnou režii. PHP nedělá moc optimalizací a vyhrabat třídu a v ní statickou metodu prostě chvilku trvá.

Zkus vyrobit prostou funkci bez té obalující třídy. Pak zkus vyrobit instanci třídy Validator a odstranit "static" od metod. A hoď sem výsledky (i s těmi minulými pohromadě).

[OldFrog {Ondra Nemecek}]

# Checked via static Validator::notEmpty() in 1.84 ms
# Checked via inline expression in 0.30 ms
# Checked via normal function in 1.64 ms
# Checked via object->notEmpty() in 1.87 ms

[Josef Kufner]

Co jsem tak porůznu četl, tak volání metody objektu by mělo být rychlejší než statické metody. Podivné, že ti to vyšlo naopak.

Asi s tím nic nenaděláš. Buď použij Céčkový preprocesor nebo si to nech zkompilovat pomocí Hiphopu.

Být tebou bych se ale zamyslel nad designem toho programu, protože takle obskurní testování na prázdnost je prostě divné.

[Kit]

Uvedené měření mi vlastně dokázalo, jak nesmyslné je objektové programování s jednořádkovými gettery a settery. Výsledné aplikace jsou pak líné, protože proměnné jsou testovány ještě před uložením do objektu a to znamená další režii a znepřehlednění kódu.

Je hodně podivné proměnnou testovat na číslo, řetězec a objekt zároveň. Na vstupu obvykle očekávám parametr určitého typu a testuji pouze ten typ. Pokud očekávám string, nemá smysl testovat integer nebo objekt. Obvykle stačí 2 testy, které jsou pro různé datové typy odlišné.

Ještě by mohlo být zajímavé změřit výsledky s aktivním APC, které by to mohlo výrazně urychlit a výsledky úplně změnit.

[OldFrog {Ondra Nemecek}]

U dynamicky nebo slabě typovaných jazyků si s typem jist nemusím být. Takže to je otázka přístupu.

APC výsledek nezměnil vůbec - je to jen cache bytekódu. Změnit by to mohl skutečný optimizer (JIT nebo compile-time). Zkusil jsem eaccelerator, žádná podstatná změna. A PHC nebo Raven (RPHP) se mi nepodařilo zprovoznil (nejde mi to zkompilovat) a nakonec slavný HipHop je ještě komplikovanější nasadit (musí se patchovat některý knihovny apod.).

V podstatě by se mi líbilo mít možnost kritickou část kódu zkompilovat jako extension pro php, což umožňuje třeba ten PHC.

Pro zájemce článek http://www.phpclasses.org/blog/post/117-PHP-compiler-performance.html

[Kit]

U dynamicky nebo slabě typovaných jazyků si s typem jist nemusím být. Takže to je otázka přístupu.

Pokud testuji například číslo domu v adrese a očekávám řetězec, tak budu testovat a ukládat řetězec. Nebudu se snažit ho převádět na číslo, i když ve většině případů to číslo bude. Takže vždycky vím, jakého typu ta uložená proměnná bude. Nebo mi to může být jedno a uložím to co přijde. Záleží na požadavcích na aplikaci.

Pokud naopak očekávám číslo a někdo mi tam narve string, mám podle požadavku na aplikaci na výběr, zda se pokusím ten string převést na číslo nebo ten string odmítnu. Vždy záleží na konkrétním případě vstupní hodnoty, zda budu tvrdě kontrolovat přesnost vstupů, zda se vstupní data pokusím normalizovat nebo mi to bude jedno.

Testovat všechny vstupy postupně jedním univerzálním nástrojem je IMHO blbost a aplikace na to doplatí výkonem. Mám na mysli testování po jednom. Výkonově přijatelnou variantou by mohlo být testování všech vstupů jednou třídou, která by všechny ošetřené hodnoty poskytla buď ve formě objektu, anebo třeba ve formě asociativního pole. Objekt se mi však jeví jako lepší, neboť umožňuje vytváření i jiných než primitivních getterů.

Jsem prostě zaujatý proti primitivním jednořádkovým getterům a setterům. A nestydím se za to. Jsem zastáncem toho, že setter si musí umět sám ošetřit vstupy a nesmí očekávat, že to za něj udělá někdo předtím. Tím pro mne uvedené statické validátory postrádají na významu.

[Josef Kufner]

V PHP jednořádkové gettery a settery nepotřebuješ. Prostě uděláš public proměnnou a hotovo. V okamžiku, kdy pak potřebuješ přidat getter/setter, z ní uděláš private (protected) a implementuješ magické __get a __set metody. Na API se přitom nic nezmění.

[Kit]

To jsem neměl přímo na mysli, ale spíš to, že mnozí ty jednořádkové settery píší, třeba i přes magické __set(). Vůbec však nevyužijí možnosti otestovat platnost hodnoty přímo v metodě, ale testy šmudlí v hlavním kódu ještě před uložením hodnoty do objektu. Tím se hlavní kód stane nepřehledným.

Settery moc nedělám, velmi často si vystačím s konstruktorem. Jednou vytvořené objekty se snažím nemodifikovat, záleží však na konkrétním použití.

[Filip Jirsák]

Uvedené měření mi vlastně dokázalo, jak nesmyslné je objektové programování s jednořádkovými gettery a settery. Výsledné aplikace jsou pak líné, protože proměnné jsou testovány ještě před uložením do objektu a to znamená další režii a znepřehlednění kódu.

Objektové programování nemá být rychlejší než assembler, ale má zpřehlednit program pro programátory. Rozvinutí jednořádkových getterů a setterů je jedna ze základních optimalizací, které může dělat kompilátor.

Jinak dotaz je ukázkovým příkladem předčasné optimalizace. Ztráta výkonu spojená s voláním jednořádkových funkcí bude nejspíš o několik řádů menší, než ztráta výkonu spojená s typickým nasazením PHP – zpracování zdrojového kódu pro každý požadavek, chybějící optimalizace překladače a běhového prostředí, neexistující kontext aplikace, který by umožnil kešovat data rovnou v paměti procesu atd. Pokud je tedy pro aplikaci zdržení voláním funkce kritické, zvážil bych spíš změnu běhového prostředí aplikace, která by přinesla řádově větší zlepšení výkonu.

[l4m4]

Je hodně podivné proměnnou testovat na číslo, řetězec a objekt zároveň

Jenže to je právě dáno tím, že to není objektové. Pokud by bylo, tak každý typ, kde je to zapotřebí, má svou validační metodu (resp. více), a ta se prostě zavolá. Tohle je prostě pokus o makro/šablonu v jazyce, který nic takového nemá.

[OldFrog {Ondra Nemecek}]

Jinak dotaz je ukázkovým příkladem předčasné optimalizace. Ztráta výkonu spojená s voláním jednořádkových funkcí bude nejspíš o několik řádů menší, než ztráta výkonu spojená s typickým nasazením PHP – zpracování zdrojového kódu pro každý požadavek, chybějící optimalizace překladače a běhového prostředí

Ano. Proto vidím šanci v makrech nebo JIT optimalizaci. Pokud nic funčního v PHP zatím není, kašlu na to protože ta pomalost není kritická.

Jenže to je právě dáno tím, že to není objektové. Pokud by bylo, tak každý typ, kde je to zapotřebí, má svou validační metodu (resp. více), a ta se prostě zavolá. Tohle je prostě pokus o makro/šablonu v jazyce, který nic takového nemá.

Ano, souhlasím.