Vývojáři PHP jednohlasně odsouhlasili přidání preload. Nová vlastnost má pozitivní vliv na výkon, který se zvýší o 30 – 50 %. Preload najdeme v PHP 7.4, který by měl vyjít příští rok.
(zdroj: phoronix)
PHP bude mít preload, zvětší výkon o 30 - 50 %
15. 11. 2018
21
nových názorů
-
null null (neregistrovaný)
Možná to není o tom co se řeší, ale co by se mělo řešit. Např. stringy a znakové sady, šílené kreace implicitního přetypování které byly moderní možná před 20 lety - dnes jsou tak akorát bezpečnostní riziko, multihreading, pořádný systém Exceptions - stále jsou tam věci které nejdou chytat nebo je není možné chytat jako vyjímku apod ....
-
null null (neregistrovaný)
"
The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called.If errors occur before the script is executed (e.g. on file uploads) the custom error handler cannot be called since it is not registered at that time.
" -
null null (neregistrovaný)
PS: Nevzpomenu si přesně co to bylo, řešil jsem to asi před půl rokem na php 7.1, byl to nějaký E_NOTICE nebo něco takového a dopátral jsem po zkoušení a googlování že to prostě chytat nejde, mám pocit že to bylo ve spojitosti s CLI. Ale za boha si nemohu vzpomenout co to bylo za situaci. Nejsem hňup, o tom že existují user defined error functions vím roky, ale toto fakt nešlo. Nemžu to teď najít ... možná mě to v práci trkne ...
-
Matúč Čák (neregistrovaný)
Najskôr napíšeš, že ti chýba "poriadny systém exceptions" a potom tu dávaš príklady s PHP errors. V PHP errors a exceptions sú dve rôzne veci, takže namiesto set_error_handler() treba používať try-catch-finaly bloky poprípade ako posledný záchytný bod set_exception_handler().
Exceptions sú k dispozícií už od PHP verzie 5, kedy boli zriadené ako alternatívna technológia na ošetrovanie chýb a v podstate koexistovali popri errors. S ich postupným rozvojom sa stalo bežnou praxou (napríklad v rôznych frameworkoch), že jedinou úlohou error_handler-a bolo transformovať error na exception a všetko sa už riešilo iba cez exceptions.
Od verzie 7.0 boli exceptions významne posilnené zavedením Throwable a Error tried so zjavnou ambíciou errors úplne nahradiť. Vo verzií 7.1 bolo množstvo knižničných funkcií pozmenených v tom zmysle, že miesto error generujú už len Error exception a tento trend pokračuje. Myslím, že najneskôr vo verzií 8.0 už žiadne errors vôbec nebudú prítomné, každopádne aj v aktuálnych verziách PHP už skutočne len ťažko nájdeš niečo, čo by sa nedalo cez exceptions ošetriť. Samozrejme, ak je top level script neparsovateľný kvôli syntaktických chybám a vôbec sa preto nespustí, tak takáto chyba sa kódom toho scriptu zachytiť nedá, ale to je myslím celkom logické.
Vo všeobecnosti - treba si uvedomiť, že PHP je tu už takmer 25 rokov a stále sa vyvíja (a podľa mňa v zásade dobrým smerom).
-
null null (neregistrovaný)
@Matúč Čák
No právě, připadne mi to neucelené. Ale to je jen můj názor a na to jsem byl tázán. To co jsem napsal nebylo, nemělo být, není a nebude žádné technické resumé. Prostě po 8 letech denodenní práce s php mi připadne, že systém errors a vyjímek by chtěl zrevidovat a ucelit. Ty si to nemyslíš? Fajn ...
Ano php je tu 25 let. Minule jsem ho taky tak hájil - prostě jsou tam staré věci a změny se musí udát nějakým tempem. Ale to neznamená že je všechni v pohodě ....
-
null null (neregistrovaný)
@johny cash
Tak zaprvé je tam nejenom E_PARSE. za druhé byla otázka co nejde chytat a za třetí jsem do "PS" hned pod to napsal ještě dovysvětlení toho jak jsem to myslel. Jenže k tomu by se nedalo zas tolik pindat, hádat čeho je kdo vývojář apod., že?
Co je to ty nesmysly a nejde v C - jako by na tom záleželo? Kdo zvolil C jako etalon? -
null null (neregistrovaný)
@johny cash
Ano, C++, pardon. Ale neviděl jsem tam proč a kdo to vybral jako etalon. Já ne. Error který jsem zaznamenal jsem zaznamenal a bylo kolem toho co jsem napsal. Pokud si myslíš že kecám, fajn, no a co? Co jsem tehdy řešil už neodřeším, poctivě přiznávám že to momentálně neprokážu. Mysli si o tom co chceš, ale není to důvod abys vedl hněty typu "Vy budete asi ... blá blá".
Systém errorů podle mě chce v php ještě dopracovat. Je to podle mě tím, že do systému errorů se přidaly exceptions ale jenom někam. Nějak jdou zapnout/vypnout, jdou nastavit error levely, custom handlery a pak je v tom akorát zmatek a člověk neví co může čekat co, kde, kdo a jak pustí a ještě ke všemu dohromady s brutálně širokými možnostmi implicitního přetypování to dává velmi nejisté pole.
Zvykl jsem si na to, počítám s tím, nijak kvůli tomu php nehaním, jenom si myslím že to je větší problém než rychlost. Ale dokážu pochopit že vyřešení zrovna tohoto je zase obtížnější co se šířky zásahu do systému týče. To ale neznamená že to podle mě není potřeba. Udělalo by to z php o moc lepší jazyk ... -
Matú Čák (neregistrovaný)
K tomu implicitnému pretypovaniu. Toto rozhodne nie je nejaký PHP špecifický problém, ale týka sa v podstate všetkých dynamicky typovaných jazykov ktoré už existujú nejakú dobu, lebo ako správne píšeš, kedysi to bolo moderné. Vynikajúce video na túto tému (spomína sa tam ruby a javascript):
https://www.destroyallsoftware.com/talks/wat
Na druhej strane si ale myslím, že tento problém sa preceňuje. Dnes už väčšinu kódu píšeš OOP štýlom takže 99% typov s ktorými pracuješ, sú objektové triedy a tam sa žiadne problémové pretypovanie nedeje. Navyše v aktuálnych verziách PHP máš už k dispozícií plnohodnotnú typovú kontrolu vstupných parametrov a návratových hodnôt metód, takže problém ti môže vzniknúť akurát tak izolovane, vo vnútri metódy a na to spravidla dôjdeš pri unit testoch.
No a v neposlednom rade treba tiež povedať, že v PHP takéto konverzie postupne odstraňujú, aj keď z dôvodu spätnej kompatibility je to samozrejme beh na dlhú trať. Napríklad sa aktuálne takto odstraňuje automatická konverzia nedefinovaných konštant na stringy - od verzie 5 to generovalo Notice, od 7.2 Warning a od 8.0 to má byť tvrdý Error.
-
PS: Nevím jak to je teď, ale samotný include/require byl zoufale neefektivní, zejména pokud se načítalo mnoho souborů a nepoužíval se autoloading. Neefektivnost spočívala v kontrole, zda se má skript znovu načíst nebo ne, takže ani opcache nepomohla. Na pomalejším síťovém úložišti to dokázalo zabít výkon a existovaly na to bugreporty. Pokud bude teď opcache persistentní (bude?) a bude se přednačítat předem, mohou se tyto kontroly vynechat - a možná právě toto je důvodem zlepšení (neověřoval jsem). Pokud by to měl někdo nastudované, nechť se podělí...
-
em (neregistrovaný)
Při použiti opcache.validate_timestamps = 0 se žádné kontroly neprovádějí už dnes.
Smysl preloadu je úplně v něčem jiném - popsané je to v https://wiki.php.net/rfc/preload -
Precital som si prvy odstavec a setsakra mi to pripomina cestu ktorou idu precompiled headers v C/C++. Na vacsich projektoch to dokaze zrychlit kompilaciu, ale ked projekt prerastie nejaku velkost, tak naopak precompiled headers zacnu sposobovat problemy. Typicky je to nedeterminizmus v tom, co je skutocne v module nadefinovane a nadeklarovane a kam vsade sa moja deklaracia, ktoru strkam do headera, ktory sa zucastnuje na PCH dostane.
Ocakavam vlnu (aj bezpecnostnych) chyb v roznych PHP frameworkoch a aplikaciach plynucich z tohto nedeterminizmu. My sme si s PCH uzili fakt vela srandy.
