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.
Slo 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...
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?