Názor k článku Vývoj PHP 6 od Pavel Tišnovský - On tu neinlineovanou kopii ponechat nemusi, protoze z...

On tu neinlineovanou kopii ponechat nemusi, protoze z kontextu vi, ze se ta funkce nikde jinde nepouzije (to samozrejme plati pouze pro funkce deklarovane jako inline nebo static). I funkce nadeklarovane "inline", ktere se prekladaci nelibi, se nemusi linkovat primo do kodu - to ostatne rika i norma. Vzhledem k tomu, ze se mi zatim darilo jako inline funkce delat opravdu kratke kody (klasicke jsou settery a gettery), tak to GCCcko vzdycky prelozilo tak, jak jsem potreboval.

Ja jsem JITko testoval na verzich 1.4 a 1.5, ta jedna-petka mela aplikovane nejake bug-fixy, ale urcite to neni nejnovejsi vec, spis tak o rok pozadu. Ano, ta rezie je opravdu velka, takze pro mensi utility, ktere se casto pousti, se to nehodi (to je jedna z veci, ktera mi na cele platforme Javy hodne vadi). Na druhou stranu napriklad TomCat nebo JBoss spousti Javovske servlety rychleji, nez Apache Perlovske skripty :-).

BTW, vzdycky jsem povazoval kod vylezly z cecka za "neprenositelny" v tom smyslu, ze cecko je vlastne urceno k tomu, aby se mezi platformami prenasely zdrojaky a ne binarky, u kterych se preklad provadi tak, ze se zvoli "nejmensi spolecny jmenovatel" vsech cilovych platforem. Protoze preklad binarky pro predem nezname platformy prakticky vzdy vyprodukuje neefektivni kod, napriklad dnes je porad popularni preklad pro i386, dnesni procesory toho umi podstatne vice (MMX, SSE2, pipelining atd.). Takze distribuce binarky, pokud to tedy neni osetreno nejakymi testy a vyberem spravne vetve kodu podle procesoru (objemova neefektivita), to cecko strasnym zpusobem degraduje, nehlede na to, ze nektere veci nejdou na i386 vubec napsat (napriklad multiprocessing ma podporu v jedne instrukci az i486, ale ten se stejne na platforme PC moc neujal). Z toho vyplyva, ze duraz na efektivitu prelozeneho kodu je na uzivateli (resp. jeho spravci), ktery by mel preklad provest tak, aby to bezelo co nejrychleji (-O3, -march atd. atd.).

Nebo se na celou efektivitu muzeme vyflaknout a pouzivat moderni i lety osvedcene dynamicke jazyky, ve kterych se aplikace pisou mnohem rychleji nez v cecku a nehrozi pritom to, ze jsem zrovna nedavno objevil v jedne bezne prodavane aplikaci za cca 120 000 Kc dosti usmevny memory leak.