Ty optimalizace HashMap a TreeMap mně přijdou jako samoúčelná honba za benchmarky. On na světě existuje někdo, komu připadá normální HashMap pomalá? To bych se podivil. Zato určitě existuje pár lidí (včetně mě), kteří ji považují za dost paměťově nenažranou. Proč Javové aplikace žerou tolik heapu už po nabootování? Kvůli paměťové náročnosti String (zejména) a HashMap (programátorské hujerství teď vytýkám před závorku). Je škoda, že se někdo v r&d JDK nezaměří tímto směrem a člověk si to musí dělat sám. (A v článku zmíněná optimalizace Stringu není dostačující; btw proč je String.intern() tak zoufale pomalé? Zjevně paměť není priorita...)
Problem je, ze dobre vysledky benchmarku pomahaji prodeji app.stacku, proto se taky vsechny firmy nabizejici zelezo+OS+JVM+aplikacni server snazi o co nejlepsi vysledky, zejmena prave ve SPECjbb.
Pro zajimavost se podivejte, na cem spousti benchmarky IBM, je to moc pekny kousek hardwaru:
http://www.spec.org/jEnterprise2010/results/res2010q1/jEnterprise2010-20091207-00003.png
Jinak snahy o snizeni pametovych naroku pri startu JRE tady jsou jiz nekolik let, uvidime co se podari v JDK8 (v sedmicce se uz nedockame ;-).
Mohu se zeptat, kde je problem se Stringy a jejich pametovou narocnosti? Pri jejich spojovani nebo obecne v tom, ze jeden znak zabere >=2 bajty?
Na String.intern() se podivam do zdrojaku, muze tam byt nejaka bota, clovek nekdy v JVM objevi opravdu prapodivne veci :-)
Tak String.intern() je skutecne reseno pomerne zajimave, pres JNI se vola (neprimo, pres nekolik dalsich metod) tato smycka:
for (int index = 0; index < length; index++) { result[index] = value->char_at(index + offset); }
result je nove naalokovane pole charu, length a offset se ziskaji z instance String. Potom se tam jeste hraje s handly, ale to uz by nemelo byt nijak narocne, nicmene to zkusim projet profilerem. Pro delsi stringy vsak skutecne muze vyse uvedena smycka nejaky cas zabrat.
Peknej clanek. Castecne souhlasim s kertem, problem performance dnesnich aplikaci neni o spojovani stringu, pripadne koleksnach. Nejvetsi problem performance je mezi klavesnici a zidli. Lidi kdyz neco implementujou tak se soustredej na problem ktery chtej vyresit, ale na zpusob jak to udelat uz kaslou. Nejvetsi zlo z tohodle pohledu jsou "Frameworky" jako Hibernate, kdo nevi jak Hibernate pouzivat at na nej nesaha, ono je totiz desne jednoduchy iterovat pres kolksnu, nebo si sahnout na objekt referncovany z jineho objektu, ale to zverstvo co se deje v DB uz nevidi.
HashMapa by se jiste dala optimalizovat, nicmene by to vyresilo pramalo problemu. Kert mel pravdepodobne na mysli, ze instance tehle dvou class vetsinou zabiraj nejvic heapu. Ale za to muzou programatorska cunata ;) Reseni je cune napomenout rict mu at se nad tim zamysli, a pokud nic nevymysli a je tam hodne duplikatu tak at vyzkousi intrnaci. Nicmene Intern je opravdu pomaly.
Jasne, to spojovani stringu a prace s mapami byl pokus o udelani jednoducheho testu, kde by se ukazalo pripadne zrychleni. Ja mam i vysledky SPECjbb a SPECjvm, ale problem je, ze je nemuzu zverejnit kvuli licencnimu ujednani.
Frameworky a obecne dalsi black boxy pridavane do aplikaci jsou urcite v mnoha pripadech problem, stejne jako napriklad pouzivani defaultnich nastaveni aplikacnich serveru, i kdyz si mnoho aplikaci "dotahuje" svoje balicky, ktere funkce serveru kopiruji - potom je v pameti napriklad X trid resicich SAX ci DOM atd. a heap se "utesene" preplnuje ;-)
Pustit si Hibernate v logovacim rezimu (kde se mu vypisuji generovane SQL prikazy) by ale programator mel zvladnout, jinak je to dost spatny ne?
Což o to, většinou to není problém zapnout (když je to potřeba).
Ale proč by to dělal? Když:
1. Aplikace funguje a nikdo si nestěžuje, že je tam s čímsi "problém".
2. Zapnutí týhle featury obvykle způsobí, že se Vám budou plnit logy tunama "SQL-spamu" (když už, tak si to nechám formátovat, že;-)), což v situaci, kdy potřebujete v console-logu sledovat regulérní chybový zprávy při startu serveru (aplikace), znamená, že snadno přehlídnete důležitý věci.
3. Vývojář je placenej nikoliv za to, jak *rychlou* aplikaci vyrobí, ale za to, jak *rychle* tu aplikaci vyrobí.
K tomu je potřeba si uvědomit, že:
1. Cena práce vývojáře je obvykle dražší než ten HW, na kterým to bude ty 2 roky běžet:-(
2. V průběhu výroby aplikace dochází ke změně (dospecifikovávání) požadavků, což vede k tomu, že se (z výše uvedených důvodů) do kódu "dolepujou" ke stávajícímu řešení rychlý změny a workaroundy:-(