Názory k článku
Využití skrytých vlastností JDK (1)

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...)

Vsadil bych se ze mas 64bit system. Existuje prepinac na kompresi pointru na 32bitu, dost to pomaha.

Problem je, ze dobre vysledky benchmarku pomahaji prodeji app.stacku, proto se taky vsechny firmy nabizejici zelezo+OS+JVM+a­plikacni 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?

Nema byt nahodou u druheho prikladu se tridou String pouzit prepinac -XX:+UseCompres­sedStrings pro natazeni alt-string jaru?

JRockit R28.1.1 alt-rt.jar alt-string.jar neobsahuje. Parametr k jejich pouziti taky ne.

kvalitni prace, dik