Vlákno názorů ke článku DI? Rozhodně ano! DI framework? Děkuji, nepotřebuji od kvr kvr - Přijde mi, že tenhle seriál je v prvé...

Přijde mi, že tenhle seriál je v prvé řadě postavený na špatné logice. Tenhle článek to vystihuje - na začátku představí něco úplně špatně a argumentuje, proč je špatně, pak představí ještě jedno řešení, které je dost špatně a následovně logickou úvahou dojde k tomu, že jiné řešení tedy musí být správně a představí to svoje. Takhle logika nefunguje.

Proč jsou statické providery špatně, bylo už diskutováno několikrát, a existuje na to spousta článků. Ano, je to problém v PHP, že vytvoření aplikace pro každý request je drahé. Na druhé straně existují řešení - design patterny proxy a lazy loading. Čekal bych, že PHP frameworks budou používat něco podobného, ale znalec toho světa moc nejsem.

Moderní PHP FW to běžně používají. Nette a Symfony drží celkem slušný standard v tom, jak se věci mají dělat podle zkušeností, které jsme jako ajťáci získali za celou historii naší profese. Není to problém jazyka nebo PHP světa. Stejně jako filtruju odpad v Javě, C#, Rustu, tak filtruju odpad v PHP.

Pak jsou samozřejmě projekty, které jsou z různých důvodů legaci. Někdy proto, protože existují už dlouho a tak si to sebou táhnou. Někdy proto, že autoři prostě nemají zkušenosti - příklad Davida Grudla před patnácti lety (Nette 0.9 používalo SL), nebo Mirek Marek aktuálně. David se během těch patnácti let posunul, a nyní patří mezi lídry PHP komunity. Přeji mu, aby se to Mirkovi Markovi časem podařilo taky.

Tak to aj v PHP praxi vyzera. Mnozstvo ludi ci su seniori len vdaka tomu ze niekde patlali kod viac ako 3 roky.

Early loading (koli DI cez konstruktory) je pouzitelny akurat tak pre male ptojekty, kde sa paralelne nespracovava mnozstvo requestov. Jadro totiz nemoze alokovat pamat pre viacero procesov sucastne, iba pre jeden, ostatne cakaju na zamok. To vo vysledku sposobi ze request rychly v dev(necaka na zamky) na servri da odpoved v radovo sekundach. A zakaznici neradi vidia ze im google vyrazne penalizuje rate. Lenze lopaty aj tak odmietaju lazy loading, pretoze chyba nie je medzi klavesnicou a stolickou, ale logicky v PHP.

Mě pořád fascinuje, jak ostatní označujete za lopaty, ale sám tady píšete naprosté nesmysly.

Jádro opravdu nemá úzké hrdlo v jednom zámku na alokaci paměti. Ve skutečnosti drtivá většina alokace paměti vůbec ani nejde do jádra. A ani v rámci jednoho procesu tam není jeden zámek - moderní alokátory mají různé per thread nebo per core pools apod - https://en.wikipedia.org/wiki/C_dynamic_memory_allocation#jemalloc .

Zpomalení na produkci je typicky způsobeno větším množstvím dat a jejich neefektivním zpracováním (špatná datová struktura, neefektivní vyhledávání, chybějící indexy v DB apod), případně resource contention v databázi či jinde. Zrovna lazy loading se projeví lineárně stejně v dev či produkci.

Nekrm trolla :-)

Bavime sa o posix systemoch s jadrom beziacimv ring 0. Ste tak blby ze si ani nedokazete precitat co linkujete?

To je neuvěřitelná snůška blbostí, opět jsi nezklamal :-)

Za prvé - žádnej garbage-collected jazyk, PHP nevyjímaje, opravdu kvůli každýmu new nevolá malloc nebo podobně. Alokujou si větší kusy předem a s těma si pak hospodaří samy.

Za druhé - to, jestli se ty věci vytvoří všechny najednou nebo lazy v průběhu requestu, je snad jedno? Dřív nebo pozdějc se ten new zavolat musí. Nebo jako všechny requesty přijdou úplně najednou, takže v prvním případě se čeká na zámek a v druhým ne?

Pořád trochu doufám, že jsi troll, protože možnost, že někde reálně běží software, kterej jsi napsal, je docela děsivá...

je
Tárá úplně stejné nesmysli všude.

Pamet sa alokuje po blokoch aj pre procesy ktore nemaju garbage collector, akurat server koli moznemu velkemu poctu subezne beziacich procesov tie bloky nealokuje prilis velke, to by za chvilu dosla pamat. K tomu aby garbage collector fungoval, je nutne co najviac pamate alokovat v lokalnom kontexte ulohy, nie pred alokaciou objektu, je to takmer rovnaky fail ako globalny kontext alebo singleton(casto vyuzivany pre facade). Taktiez je nutne pribezne odosielanie obsahu klientovi a dealokacia prislusnych bufrov, tie tiez zaberaju pamat.

Nie je to jedno. Meria sa cas od odoslania requestu po pripojenie na server. Google a pravdepodobne s tym zacnu aj dalsi, meria cas od pripojenia na server po prvu odpoved so servra. Je teda daleko vyhodnejsie odosielat obsah asap, ako ho odosielat az na koniec, po tom co sa vykona zazrazny kod nejakeho mentalneho atleta. Potom sa recykluje uvolnene miesto a nie je nutne v ramci requestu alokovat dalsiu a dalsiu pamat.

New sa musi zavolat tak ci tak. Ale pri lazy loadingu sa vola len ten nevyhnutny new, kdezto ked pouzijete DI cez konstruktor, tak musite alokovat vsetky objekty ktore ma ten konstruktor dostat, vratane tych ktore sa realne nepouziju.

Casto dostavam ponuky typu "ono nam to funguje, len to treba doladit a opravit". To desive pre vas moze byt len to, ze po par kolach konzultacii budete mat vela volneho casu.