abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 16:00 | Nová verze

Byl vydán Mozilla Firefox 51.0. Z novinek lze upozornit například na upozorňování na přihlašování přes nešifrované spojení (HTTP), podporu pro přehrávání bezeztrátového formátu FLAC nebo podporu WebGL 2. Podrobné informace v poznámkách k vydání a na stránce věnované vývojářům. Řešeny jsou také bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
včera 17:25 | IT novinky

Do prodeje (Farnell) se dostal jednodeskový počítač Tinker Board (unboxing). Jedná se o konkurenci Raspberry Pi 3 od společnosti Asus. Porovnání (jpg) těchto počítačů například na CNXSoft. Cena Tinker Boardu je 55 £.

Ladislav Hagara | Komentářů: 14
včera 14:44 | Zajímavý projekt

Byla zveřejněna pravidla hackerské soutěže Pwn2Own 2017, jež proběhne od 15. do 17. března v rámci bezpečnostní konference CanSecWes ve Vancouveru. Soutěžit se bude o více než milion dolarů v pěti kategoriích. Letos se bude útočit i na Ubuntu. Jedná se již o 10. ročník této soutěže.

Ladislav Hagara | Komentářů: 2
včera 13:33 | Nová verze

Po sedmi měsících vývoje od vydání verze 5.7 byla vydána verze 5.8 (YouTube) toolkitu Qt. Z novinek lze zmínit například Qt Lite pro vestavěná zařízení. Nově jsou plně podporovány moduly Qt Wayland Compositor (YouTube) a Qt SCXML (YouTube). Současně byla vydána verze 4.2.1 integrovaného vývojového prostředí (IDE) Qt Creator.

Ladislav Hagara | Komentářů: 1
včera 11:52 | Pozvánky

Lednový Prague Containers Meetup se koná ve čtvrtek 26. ledna 2017 od 18:00 v Apiary, Pernerova 49, Praha 8. Přijďte se podívat na přednášky o Enterprise Kubernetes a Jenkins as a code.

little-drunk-jesus | Komentářů: 0
včera 11:40 | Pozvánky

Program letošního ročníku konference Prague PostgreSQL Developer Days, která se koná již 15. a 16. února 2017 na ČVUT FIT, Thákurova 9, Praha 6, byl dnes zveřejněn. Najdete ho na stránkách konference včetně anotací přednášek a školení. Registrace na konferenci bude otevřena zítra (24. ledna) v brzkých odpoledních hodinách.

TomasVondra | Komentářů: 0
22.1. 02:20 | Zajímavý článek

David Revoy, autor open source webového komiksu Pepper&Carrot nebo portrétu GNU/Linuxu, upozorňuje na svém blogu, že nový Inkscape 0.92 rozbíjí dokumenty vytvořené v předchozích verzích Inkscape. Problém by měl být vyřešen v Inkscape 0.92.2 [reddit].

Ladislav Hagara | Komentářů: 0
22.1. 02:02 | Komunita

Øyvind Kolås, hlavní vývojář grafických knihoven GEGL a babl, které využívá grafický program GIMP, žádá o podporu na Patreonu. Díky ní bude moci pracovat na vývoji na plný úvazek. Milník 1000 $, který by stačil na holé přežití, se již téměř podařilo vybrat, dalším cílem je dosažení 2500 $, které mu umožní běžně fungovat ve společnosti.

xkomczax | Komentářů: 12
21.1. 23:54 | Pozvánky

DevConf.cz 2017, již devátý ročník jedné z největších akcí zaměřených na Linux a open source ve střední Evropě, proběhne od pátku 27. ledna do neděle 29. ledna v prostorách Fakulty informačních technologií Vysokého učení technického v Brně. Na programu je celá řada zajímavých přednášek a workshopů. Letos je povinná registrace.

Ladislav Hagara | Komentářů: 0
21.1. 22:11 | Nová verze

Byla vydána verze 1.0.0 emulátoru terminálu Terminology postaveného nad EFL (Enlightenment Foundation Libraries). Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (12%)
 (2%)
 (72%)
 (3%)
 (11%)
Celkem 395 hlasů
 Komentářů: 39, poslední dnes 19:30
Rozcestník
Reklama

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

16.11.2011 11:48 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Režie spojené s voláním funkce versus inline expression
Přečteno: 311×
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!
-- OldFrog

Odpovědi

16.11.2011 12:01 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
PS: Používám PHP Version 5.3.8.
-- OldFrog
16.11.2011 12:54 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
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).
Ještě na tom nejsem tak špatně, abych četl Viewegha.
16.11.2011 20:53 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
Taky možnost - musel bych to zařadit do deploymentu. Jsem myslel jestli to nejde nějak transparentně.
-- OldFrog
Josef Kufner avatar 16.11.2011 13:04 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
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?
Hello world ! Segmentation fault (core dumped)
16.11.2011 16:36 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
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.

-- OldFrog
Josef Kufner avatar 16.11.2011 18:21 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
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.
Hello world ! Segmentation fault (core dumped)
16.11.2011 19:37 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
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ě.
-- OldFrog
16.11.2011 19:50 Kit
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
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í.
16.11.2011 20:16 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
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.
-- OldFrog
16.11.2011 20:35 Kit
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
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 avatar 16.11.2011 21:31 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
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.
Hello world ! Segmentation fault (core dumped)
16.11.2011 23:40 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
Však já to všechno vim. Ale přepisovat to popsaným způsobem nechci.
-- OldFrog
16.11.2011 18:13 Kit
Rozbalit Rozbalit vše Re: Režije spojené s voláním funkce versus inline expression
"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ší.
16.11.2011 20:40 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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...
-- OldFrog
16.11.2011 20:59 Kit
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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 avatar 16.11.2011 21:33 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
A někdy je navíc vhodné rozlišovat prázdný string od neinicializovaného stringu. Tedy "" vs. null.
Hello world ! Segmentation fault (core dumped)
16.11.2011 23:32 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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 :-)

-- OldFrog
Josef Kufner avatar 16.11.2011 23:51 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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ě).
Hello world ! Segmentation fault (core dumped)
17.11.2011 00:09 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
# 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
-- OldFrog
Josef Kufner avatar 17.11.2011 00:18 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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é.
Hello world ! Segmentation fault (core dumped)
17.11.2011 11:14 Kit
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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.
17.11.2011 11:52 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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
-- OldFrog
17.11.2011 12:39 Kit
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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 avatar 17.11.2011 14:33 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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í.
Hello world ! Segmentation fault (core dumped)
17.11.2011 15:05 Kit
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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í.
17.11.2011 12:05 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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.
17.11.2011 12:22 l4m4
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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á.
17.11.2011 12:35 OldFrog {Ondra Nemecek} | skóre: 25 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Režie spojené s voláním funkce versus inline expression
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.
-- OldFrog

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.