( hajbazer | 2018. 01. 13., szo – 21:42 )

Az nem mainstream közhely, hanem a valóság. Amiről beszélni szoktál, az meg van a valóság, hanem egy elképzelt világ.

Nem elképzelt világ. "Az én világom" létezik minden desktop felhasználónál, vagy ha nem is mindnél, 100 millió embernél, akik még XP-t használnak egy nem mai gépen.

Így van. Viszont azért beszélsz hülyeséget, mert nem értesz hozzá és fel se tűnik, hogy hülyeséget beszélsz. Amikor meg az orrod elé teszik a bizonyítékot, hogy hülyeséget beszélsz, akkor nem válaszolsz, aztán teljesen másik témában vagy szálban folytatod tovább, figyelmen kívül hagyva a tényeket.

Leírtam ennek is az okát fentebb. Ha te meg ezt nem veszed figyelembe, akkor továbbra is el fogunk beszélni egymás mellett, tehát nincs nagyon értelme vitatkoznunk, legalább is erről.

Mutass pontos mérést, hogy egy ugyanarra a célra szolgáló C++-ban assembly betétekkel megírt optimalizált alkalmazás gyorsabb, mint a Java implementáció. Ne csak beszélj általánosságban, hanem mutass konkrét példát, mérésekkel, környezettel, ahogy szokás.

Ha adsz egy tool-t, amivel a teáltalad elfogadott, mérnöki™ sztenderdek szerint meg tudom mérni, hogy adott, Windows XP-n futó grafikus desktop alkalmazás mennyi idő alatt rajzolja le a widget-jeit, és mindezek függvényében mennyi CPU-t és memóriát zabál, akkor kapsz róla mérést. Addig be kell érned azzal, hogy azt mondom, hogy nekem eddig minden Java-ban írt program lassabb volt, mint egy azonos alapfunkciókkal rendelkező C++-ban írt és többet is zabált úgy nagyjából mindenből.

Például JSON serializációban az első négy helyezett JVM-en futó alkalmazás: https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json

Igen, sejtettem, hogy egy olyan ellenpéldával rukkolsz majd elő, ami az általam említett kontextustól a legtávolabb esik. Pontosan ezért írtam le az előbb:

én elhiszem, hogy te Java EE-ben írsz olyan adatbáziskezelőt, ami szarráveri az azonos C/C++ implementációkat

Ennek ellenére, a servlet kiemelkedéséből sem következik semmilyen módon, hogy a Java általánosan erőforráshatékonyabb, mint a natív kód. Pláne, hogy valószínűleg azért van így, mert többet és jobban cache-el, mint a többi, de ez által több erőforrást is zabál. Ez azt eredményezi, hogy a Dell ServerCentral Dell környezetein ő muzsikál a legjobban, tehát ott ezt éri meg a legjobban használni, már ha a JSON serializáció a szűk keresztmetszet. Az viszont már mérnök uraságod szélsőséges menedzseri idealizmusa, hogy összesített eredményt állítasz be legjobbnak, mikor latency-ben kilencedik, framework overhead-ben pedig még a TOP 10-ben sincs benne a jávád. Ha pedig ennyire szereted a számszerű méréseket, vess az alábbiakra is egy pillantást.

Itt már sajnos nem teljesít olyan fényesen a jávád. (bár ezt simán figyelmen kívül fogod hagyni, mert nem illik a koncepciódba)

Nade akkor még egyszer, hogy biztosan megértsd: elhiszem, hogy vannak felhasználási módok és környezetek, ahol a Java jobban teljesít, mint a natív kód. Az én felhasználási módom és környezetem nem ilyen és soha nem is lesz ilyen.