Odpověď na názor

Odpovídáte na názor ke článku DI? Rozhodně ano! DI framework? Děkuji, nepotřebuji.

  • 9. 5. 2023 16:59

    dw

    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.