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 13:11 | Pozvánky

Spolek OpenAlt zve příznivce otevřeného přístupu na 142. brněnský sraz, který proběhne v pátek 21. července od 18:00 hodin ve Sport Centru Srbská (Srbská 4). Od 19:00 je pro zájemce zamluveno hřiště na plážový volejbal.

Ladislav Hagara | Komentářů: 0
dnes 12:34 | Bezpečnostní upozornění

V GNOME Soubory, původně Nautilus, konkrétně v generování náhledů exe, msi, dll a lnk souborů byla nalezena a opravena bezpečnostní chyba CVE-2017-11421 s názvem Bad Taste. Při otevření složky obsahující tyto soubory může být spuštěn VBScript obsažen v názvech těchto souborů.

Ladislav Hagara | Komentářů: 1
dnes 11:00 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 308 bezpečnostních chyb. V Oracle Java SE je například opraveno 32 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 28 z nich. V Oracle MySQL je opraveno 30 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 9 z nich.

Ladislav Hagara | Komentářů: 0
dnes 01:00 | Komunita

Mark Krenz, známý svým twitterovým účtem @climagic (Command Line Magic), kde ukazuje, co vše a jak lze dělat v příkazovém řádku, přednášel včera v Praze. Záznam přednášky je k dispozici na YouTube.

Ladislav Hagara | Komentářů: 0
včera 10:00 | Nová verze

Microsoft vydal Skype pro Linux ve verzi 5.4 Beta. Nejnovější Skype pro Linux je postaven na frameworku Electron 1.7.4 a přináší skupinové videohovory.

Ladislav Hagara | Komentářů: 11
včera 06:00 | Nová verze

Werner Koch, zakladatel a hlavní vývojář GnuPG, oznámil vydání verze 1.8.0 svobodné kryptografické knihovny Libgcrypt. Jedná se o první stabilní verzi nové řady 1.8. Ta je API i ABI kompatibilní s řadou 1.7. Z novinek vývojáři zdůrazňují podporu kryptografických hašovacích funkcí Blake2 (Wikpedie), šifrovací mód XTS nebo zvýšení výkonu na architektuře ARM.

Ladislav Hagara | Komentářů: 0
18.7. 15:55 | Zajímavý projekt

Stefan Vorkoetter představil na svých stránkách DIY tablet s Raspberry Pi 3 Model B. Z Raspberry Pi odstranil USB porty, ethernetový port i GPIO konektor. Použil oficiální sedmipalcový dotykový displej s rozlišením 800x480 pixelů. Hmotnost tabletu je 484  g.

Ladislav Hagara | Komentářů: 6
18.7. 06:00 | Zajímavý projekt

Podpořit vývoj otevřených technologií pro rozpoznávaní řeči lze na stránkách Common Voice. Jedná se o projekt Mozilly, jehož prvním cílem je nahrání a následné zveřejnění pod open source licencí 10 000 hodin záznamů řeči. Pomoci může kdokoli. Stačí na stránkách projektu do mikrofonu přečíst napsaný text nebo si nechat přehrávat již nahrané záznamy a určovat, zda napsaným textům odpovídají. Podrobnosti v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 4
18.7. 05:00 | IT novinky

Do pátku probíhá v Praze IETF 99, tj. 99. setkání organizace Internet Engineering Task Force (IETF) odpovědné za tvorbu internetových standardů RFC (Request for Comments). Vybrané přednášky a jednání lze sledovat online. Záznamy jsou k dispozici na YouTube. Těsně před setkáním bylo vydáno RFC 8200 nahrazující RFC 2460 a po více než 18 letech standardizující IPv6 (STD 86).

Ladislav Hagara | Komentářů: 0
18.7. 00:33 | Nová verze

Byl spuštěn další Humble Book Bundle. Tentokrát jsou v nabídce elektronické knihy věnované kybernetické bezpečnosti od vydavatelství Wiley. Všech 14 knih lze koupit za 15 dolarů.

Ladislav Hagara | Komentářů: 0
Chystáte se pořídit CPU AMD Ryzen?
 (7%)
 (31%)
 (1%)
 (10%)
 (43%)
 (8%)
Celkem 1023 hlasů
 Komentářů: 65, poslední 1.6. 19:16
    Rozcestník

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

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