Komolytalan#29
Egy java szervert fejlesztgetek, jelenleg 3-500Mbit/sec amit tud A/V+adat szerverként (szétkapja packetekre, framet dob ha kell, újra összerakja, adatot kinyer, feldolgoz, újat belerak) - szóval nem olyan lassú az. Persze C++ gyorsabb, asm meg még gyorsabb, de én XP alatt lefordítom, linuxos szerverre feltöltöm a fordított kódot, és megy. Ezt mondjuk C++-ban szerintem senki se csinálja meg.
A java legnagyobb baja szerintem a fatengelyes memória felépítése. Erősen multithread (adja magát, hogy külön szálra rakj sokmindent), de minden közös heapbe kakál, éppen ezért nincs benne tisztességes memória felszabadításra lehetőség (majd ha a gc úgy gondolja, vagy meghívod te kézzel, akkor esetleg lesz valami). Amikor meg több 100 MBytenyi változó jön létre másodpercenként, és kerül feldolgozás után kukába, akkor egyátalán nem mindegy, hogy egy általános, de buta gc takarítja-e a memóriát, vagy normális memória foglalás, és fordított sorrendben felszabadítás van. Jelenleg elég kellemetlen az, hogy gc elindul, egyik szál közben memóriát foglalna, dob egy out of mem exceptiont, gc felszabadít 1 gigát, és a többi szál megy tovább. Ez a megoldás az én olvasatomban a gagyi szinonímája, SUN ide vagy oda.
Szálanként külön stack kéne, és döntési lehetőség hogy stackbe vagy közös heapbe teszem a változókat. Stacken nem kell gc, szál létrehozásakor lefoglalni a megadott méretet, szál befejezésekor kidobni egyben. A heapen lehet gc, oda memóriaintenzív cuccok úgyse kerülnének, ha normális a programozó.