Az ellenőrizgetésben még van is igazság, de szerintem nem az a kulcsmomentum. Manapság a legtöbb program memória sávszélesség korlátos. Egy adatbázis pláne az - tippem szerint.
Namost Java-ban ha objektumokban tárolod az adatot, akkor semmilyen ráhatásod nincs, hogy mi hova kerül fizikailag, plusz eleve van egy pár százalékos overheaded az objektumok keretei miatt (ha nem optimalizálsz direkt erre, akkor akár többszáz százalék veszteség is lehet), plusz nem tudod még az objektumon belüli dolgokat sem együtt tartani. Egy löketben cache-be kerülés helyett egy rakás memóriaművelettel (pointerek mentén ugrálva) kell végigolvasni ugyanazt az adatmennyiséget.
Ha ez nem elfogadható, akkor jön hogy tegyünk mindent tömbökbe, vagya akár ByteBuffer-ekbe. ByteBufferhez saját allokátort is írhatunk végülis, yeah! Működik, egész gyors is lesz, csak éppen absztrakció szintjén ott tartasz mintha assembly-ben akarnál adatszerkezeteket tervezni. Kicsit sajtreszelős. Ha csak pár egyszerű adatszerkezetet kell optimalizálni (pl tömböt), akkor tökéletes, a programod többi részén nyersz annyit (fejlesztési időben), amit itt vesztesz. De ha a teljes programod összes adatát ilyenekben kell tárolnod, akkor már nem akkora hawaii.
Arról nem is beszélve, hogy ha valamit csinálsz is az adatokkal (és ehhez nem írod át a programodat trükkök százaival C-szerűre), akkor minden műveletre ömleni fog a szemét a programból, aminek összeszedése elakadással jár. Egy kicsi heap-pel sem lehet a GC pause-t párszáz milliszek alá szorítani, pláne garantáltan. Tehát az időnkénti jitter a válaszidőben garantáltan ott lesz.