3 ms·
In addition to what the other reply posted, Java has had compact strings for a while now[1], which uses 8-bit `byte` arrays for `String`s, and comes in handy fo
by za3faran 3y ago
In addition to what the other reply posted, Java has had compact strings for a while now[1], which uses 8-bit `byte` arrays for `String`s, and comes in handy for ISO-8859-1/Latin-1 strings to use a single byte per character.
[1] https://openjdk.org/jeps/254 https://openjdk.org/jeps/254
- cesarb 3y agoOne annoyance with that approach is that a single non-latin-1 codepoint is enough to double the size of the String; if it were an UTF-8 String, it would only add a couple of extra bytes.
- esprehn 3y agoAt the expense of O(n) index access. At least Java and JS have compact strings. C# is always UTF-16 because they exposed too much implementation detail to be able to transparently do the compact string optimization.
- deleted 3y ago[deleted]
- morelisp 3y ago> At the expense of O(n) index access. Ah yes, that feature which means we must have 2x memory overhead and/or dynamic dispatch, yet is also totally useless in practice.
- PhilipRoman 3y agoThe fact of the matter is that there are millions of places with loops like for(...) {charAt(i)} so it is by definition useful in practice. If Java had pushed iterators more strongly, perhaps it would be possible to make the switch.
- morelisp 3y agoIn all seriousness, what's the point of having the best JIT in the world if it can't reliably transform this antipattern into an iterator?
- PhilipRoman 3y agoOpenJDK seems pretty averse to including special case optimizations, otherwise I'm sure we would have intrinsics at least for ArrayList/HashMap containing boxed primitives. AFAIK they are still noticeably slower than plain arrays or manually inlined implementations. For the most basic case you wouldn't even need JIT support - just keep a cache field of the last index accessed and where it ended and decode based on that.