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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 0
dnes 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 0
včera 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 17
včera 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 2
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

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

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 50
5.12. 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 10
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 26
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (8%)
 (5%)
 (3%)
Celkem 780 hlasů
 Komentářů: 50, poslední 29.11. 15:50
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: 310×
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.