- Luck Dragon: Asszociációs játék. :)
- MasterDeeJay: Sikeres CoffeeTime modok
- Lalikiraly: Commodore The C64, Ultimate
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- mefistofeles: Az elhízás nem akaratgyengeség!
- Tóth Olivér: Tudtátok hogy ez ma már RETRO?
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Elektromos rásegítésű kerékpárok
- Doky586: SecureBoot kulcsok frissítése (2026 nyara)
-
LOGOUT

Új hozzászólás Aktív témák
-
skoda12
aktív tag
válasz
#25954560
#7065
üzenetére
Lehet, hogy nem olyan fejlett a gc vagy tobb memoriat foglal egy azonos hosszu string, mint egy masik nyelvben. Nyilvan byte kod miatt sosem lesz olyan gyors, mint egy nativ alkalmazas. Ettol fuggetlenul azt allitani, hogy ugyanaz a program tobb tucat peldanyban fut .NET-ben ugyanazon a vason, mint egy javas peldany azert az tobb, mint meredek. Eleve nem hiszem, hogy barki itt levo latott volna egy .NET-es meg egy javas alkalmazast, amiknek ugyanaz lenne az architekturaja es ugyanazt csinaljak, igy kar is belemenni abba, hogy ez a program ennyit eszik a masik meg annyit.
Most egy olyan rendszert raktunk ki productionbe, ami majdnem 2x16 giga memoriat fogyaszt. Ettol most a java szar? Nem (illetve nem ettol szar), egyszeruen csak arrol van szo, hogy a beerkezett tradeket par millisec alatt kell feldolgozni es ebbe nyilvan nem fer bele az, hogy elkuldunk tobb sql queryt egy DB szerver fele, amik egyenkent osszejoinolnak 2-3 tobb tizmillios tablat, ezert egyszeruen a memoriaban vannak tartva az aktiv adatok.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: Central PC számítógép és laptop szerviz - Pécs
Város: Pécs


