- Magga: PLEX: multimédia az egész lakásban
- NASsoljunk: ZyXEL NSA-310 és az FFP
- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- GoodSpeed: Samsung Galaxy SmartTag2-esek a tolvajok ellen!
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- eBay-es kütyük kis pénzért
- Argos: Szeretem az ecetfát
Új hozzászólás Aktív témák
-
floatr
veterán
válasz
Aethelstone #6854 üzenetére
Lehet h nem jött le, de szabályozott init-re gondoltam, nem AS módszer szerint.
Annyi felesleges kört futottunk már ezekkel a dolgokkal, és mindig csak magunkat szívattuk meg azzal, hogy még ezt is optimalizálni akartuk. Ha annyira teljesítménykritikus az alkalmazás, hogy nem bír kivárni egy connection-nel annyit, hogy a jsp legyártja az output-ot -- ugye lefordított classról beszélünk itt is, akár egy controller/service esetében -- akkor ott már nem ezen fog múlni a dolog, hanem már magán a perzisztencián és az adatbázison. A jsp nagyságrendileg hamarabb végez, mint amennyi ideig tart az adat előállítása.Ha most egymás után lerajzolgatod egy grafikonra, hogy mi mennyi ideig tartott: pl. entity lekérdezés, 2-3 külön init, beanmap/reflection alapú konverziók kontra entity, 1-2 init, rakat println meg még 1-2 init, akkor az esetek nagy részében azt fogod látni, hogy a grafikonon a 100%-ból elég kis szeletet harap ki a JSP, akárcsak a konverziók. Ismerek olyanokat, akik képesek nagyon lassú JSP-ket gyártani, de ez szerencsére a ritkábbik eset. Még a velocity/freemarker feldolgozás is lényegesen gyorsabb, mint az IP alapú adatműveletek.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged