Sovereign Tech Fund oznámil finanční podporu následujících open source projektů: Scala, SDCC, Let's Encrypt, Servo, chatmail, Drupal, Fedify, openprinting, PHP, Apache Arrow, OpenSSL, R Project, Open Web Docs, conda, systemd a phpseclib.
Bylo vydáno OpenBSD 7.8. S předběžnou podporou Raspberry Pi 5. Opět bez písničky.
Valkey (Wikipedie) byl vydán v nové major verzi 9.0. Valkey je fork Redisu.
Byly publikovány informace o kritické zranitelnosti v knihovně pro Rust async-tar a jejích forcích tokio-tar, krata-tokio-tar a astral-tokio-tar. Jedná se o zranitelnost CVE-2025-62518 s CVSS 8.1. Nálezci je pojmenovali TARmageddon.
AlmaLinux přinese s verzí 10.1 podporu btrfs. XFS bude stále jako výchozí filesystém, ale instalátor nabídne i btrfs. Více informací naleznete v oficiálním oznámení.
Společnost OpenAI představila svůj vlastní webový prohlížeč ChatGPT Atlas. Zatím je k dispozici pouze na macOS.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.5 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.
Rodina jednodeskových počítačů Orange Pi se rozrostla (𝕏) o Orange Pi 6 Plus.
Na Humble Bundle běží akce Humble Tech Book Bundle: All Things Raspberry Pi by Raspberry Pi Press. Se slevou lze koupit elektronické knihy od nakladatelství Raspberry Pi Press a podpořit Raspberry Pi Press, Raspberry Pi Foundation North America nebo Humble.
Přidaný režim autonomního řízení vozidel Tesla Mad Max je dostupný pro vybrané zákazníky v programu EAP (Early Access Program). Nový režim je na silnici agresivnější, častěji mění pruhy a ne vždy dodržuje rychlostní limity. Agentura JPP spekuluje, že v Česku by se mohl nový režim namísto Mad Max jmenovat Mad Turek...
Pomerne malým zásahom do zdrojákov Zend Framework-u je možné získať zaujímavý boost.
Nedávno som narazil na pomerne zaujímavo písanú online knihu s typmi a trikmi, týkajúcimi sa efektívneho využívania Zend Frameworku pri vývoji webových aplikácií. Výkonovej optimalizácii sa venuje celá jedna kapitola. Tam sa možno dočítať, že knižnice ZF sú doslova vystlané príkazmi require_once()
. Tie sa počas runtime načítavajú zvyčajne zbytočne, nakoľko ZF implementuje vlastný autoloader. Naťahované súbory sa zbytočne čítajú z disku a sú zbytočne parsované serverom.
V knihe je doporučuje príkazy require_once()
v rámci zdrojákov ZF zakomentovať, k čomu autor hneď uvádza shell skript, ktorý nám toto zaistí. Ani som len netušil aké zrýchlenie môže tákáto jednoduchá zmena priniesť. Okrem toho sa v knihe doporučuje nahradiť pomerne komplexnú triedu Zend_Loader nejakým jednoduchším kódom. Napísal som teda tú najjednoduchšiu implementáciu autoloadingu v PHP (funkcia __autoload()
) s čo najmenšou réžiou a otestoval aj toto.
Nakoľko som testoval pod Win Vista, napísal som si pre zakomentovanie príkazov vlastný PHP cli skript. Na testovanie som použil Quick Tutorial aplikáciu z oficiálnych stránok ZF. Jedná sa o pomerne malú aplikáciu, ale obsahuje aj pokročilejšie veci ako napr. komunikácia s databázou (SQLite), formulár a generátor ASCII captcha.
Testoval som prvé tri stránky, zápis do DB som netestoval, nakoľko ma zaujímala iba rýchlosť samotného frameworku (dispatchingu). Na prvom a poslednom riadku index.php
som si do premenných uložil micročas (funkcia microtime()
) a potom vypočítal ich rozdiel, čím som získal čas generovania stránky. Výsledok som ukladal to súboru ako plaintext.
Testovanie prebiehalo na mojej lokálnej mašine (Intel C2D E8200@3.2GHz, 4GB RAM, Vista 32b), ako browser som použil FF v3.0.8, ako server Apache 2.2, PHP 5.0.6. Systém mám pomerne čistý, osekaný a optimalizovaný, takže počas testu ma neobťažovalo žiadne hrabanie disku alebo something like that. Nepoužil som žiadne pokročilé benchmarkovanie, jednoducho som v browseri 10x zobrazil danú stránku, z textového súboru som získal časy, tie som spriemeroval a zaniesol do grafov. No a tu už sú namerané výsledky (v sekundách).
http://zendquickstart/
1. Zend FW: 0,370390725 2. Zend FW modified: 0,218486619 3. Zend FW modified + Srigi_Loader: 0,220104504
Už indexová stránka ukazuje tretinové zrýchlenie modifikovaných knižníc. Naopak vlastný loader nijaké zrýchlenie nepriniesol. Implementácia Zend_Loader je teda na dobrej (rýchlej) úrovni, loader netreba vymieňať.
http://zendquickstart/guestbook
1. Zend FW: 0,408349991 2. Zend FW modified: 0,276227617 3. Zend FW modified + Srigi_Loader: 0,275886512
Stránka s výpisom príspevkov ukazuje menšie zrýchlenie, asi kvôli komunikácii s databázou.
http://zendquickstart/guestbook/sign
1. Zend FW: 0,914611769 2. Zend FW modified: 0,449567389 3. Zend FW modified + Srigi_Loader: 0,446687531
Stránka na pridanie nového príspevku naťahuje triedy Zend_Form a Zend_Captcha (naopak vôbec nekomunikuje s databázou), štandardné ZF knižnice teda naťahujú kopec balastu, ktorý sa parsuje zbytočne. Zrýchlenie je veľmi markantné.
Tiskni
Sdílej:
šlo by to otestovat ještě proti nějaké cache (například APC)?
Právě proto.
Upravovat knihovnu po každé aktualizaci se mi nechce: nikdy bych si nebyl jist, zda jsem tam nezanesl chybu.
APC používám a předpokládám, že by ty rozdíly mezi testovacíma verzema významě snížila.
Doporucuju taky zkusit e-accelerator misto APC, je jeste o neco rychlejsi a je na nem i znat, kdyz se mu v konfiguraci zapne optimalizaci kodu. Mimo jine nabizi rozsirenejsi praci se sdilenou pameti, bohuzel pro nej ZF zatím nemá v jádre cachovaci backend - kteryzto jsem si behem par minut napsal sam, staci forknout a zmenit par nazvu funkci u Zend_Cache_Backend_Apc :]
Nejsem si jistý, který dokument vznikl první, ale všechny důležité optimalizace jsou už dávno napsány přímo v manuálu ZF, konkrétně trik se zakomentováním require_once: framework.zend.com/manual/en/performance.classloading.html#performance.classloading.striprequires