Vlákno názorů k článku Pohled pod kapotu JVM - průchod hodnotami atributů objektů uložených na haldě (heapu) od Chytrolin - V tabulce jednoduchych tyopu je napsano ze char...
-
Rax (neregistrovaný)
Mít stringy uvnitř aplikace v UTF-8 je produkt chovanců Chocholouška, protože se u každého znaku musí pracně zjišťovat, kolik byte vlastně má a proto se UTF-8 používá jenom pro uložení dat mimo aplikaci, například do XML nebo do databáze.
Java by se s použitím UTF-8 tedy ještě zásadně zpomalila.
A pomalost Javy není ani náhodou způsobena tím že stringy mají dva byte na znak. -
Pokud budu vycházet z předpokladu, že nejčastějšími operacemi nad řetězci jsou kopírování, sčítání, porovnání řetězců a hledání podřetězce, tak ani při jedné z těchto operací se nemusí provádět zjišťování velikosti každého znaku v řetězci - naopak tyto operace budou rychlejší z důvodu téměř poloviční velikosti. Díky tomu můžete mít lepší využití CPU cache, můžete lépe využít operační paměť - velké množství řetězců se drží v různých caches.
-
Pavel TišnovskýZlatý podporovatelSlo by to relativne jednoduse - projit JVM TI agentem pres vsechny char[] a otestovat, kolik je tam znaku > 127. To stejne s constant poolem.
Dokonce je mozny si upravit tridu String, StringBuffer a StringBuilder tak, aby namisto char[] pouzivala byte[] (protoze Stringy budou urcite ty tridy, kde se char[] vyuziva absolutne nejvic) a pri cteni/zapisu provadet prevod char->byte[] (UTF-8) a naopak. Ale bude to dost pomale rekl bych, ty posuny osmibitovych hodnot...
-
kvr (neregistrovaný)
Kdyby bylo v UTF-8 úplně všechno, tak ty konverze prakticky vypadnou.
Co by se zpomalilo, jsou locale aware parsery, maps, atd. a těch je IMHO minimum (z hlediska podílu na CPU). Nehledě na to, že ty by měly správně být Unicode32 aware a tedy pomalé už tak :-)S tou úpravou je to zajímavé, zkoušel to už někdo v praxi?
-
Pavel TišnovskýZlatý podporovatel
To by chtelo otestovat na realnych aplikacich. Pravda je, ze spousta javovskych aplikaci neustale pracuje s XML, takze s UTF-8, tam ty konverze asi budou hooodne bolet. Hmm na takovym aplikacnim serveru co generuje stovky XHTML stranek za hodinu...
-
Pavel TišnovskýZlatý podporovatel
Tak zatim jsem prisel na dve moznosti jak to vyuzit - bud si zkompilovat svoji OpenJDK s upravou tridy String nebo pres xbootclasspath tam nacpat svoji tridu String v runtime, coz vsak pravdepodobne nebude fungovat dokonale (kvuli constant poolu, ktery uz bude naplneny).
-
Pavel TišnovskýZlatý podporovatel
Jeste pro jistotu doplnim, ze pokud se znak do toho rozsahu 0x0000 az 0xffff (ted to hodne zjendodusuju) nevleze, tak se ve stringu pouzije dvojice znaku. Ale v nasich koncinach to neni az tak aktualni rekl bych:)
