4 ms·
Java and JavaScript are actually hampered in that regard because they have to pretend that the encoding is UTF-16. Thus the limitation to Latin-1. With UTF-8, s
by samus 3y ago
Java and JavaScript are actually hampered in that regard because they have to pretend that the encoding is UTF-16. Thus the limitation to Latin-1. With UTF-8, seeking in the middle of the string would be harder.
- Someone 3y agoI think seeking into the middle of strings, as opposed to iterating over them from the start, is rare in most code. If so, using UTF-8 and only converting to UTF-16 the moment such seeking happens may be beneficial. Problem, however, is that Java and JavaScript have C-style for loops that give false positives, where the code indexes into the string in order to iterate over it.
- samus 3y agoThe conversion is required to properly support indexing for any index != 0. Optimizations are only possible if iterator-style APIs are used so the runtime can iterate as well. However, it might be still more efficient to convert the whole string and be done with it, depending on its length. Languages with a proper WASM backend could offer optimized runtime libraries and/or optimize such code. The issue is not new. JavaScript runtimes frequently use multiple optimized string types for various situations: https://github.com/danbev/learning-v8/blob/master/notes/string.md https://github.com/danbev/learning-v8/blob/master/notes/stri...
- Someone 3y ago> Optimizations are only possible if iterator-style APIs are used They make it simpler, but it also is possible to detect that loops are iteration-style access in disguise. That takes time, so its more likely to happen in ahead of time compiled languages. C compilers can vectorize some of such loops, so they have logic for doing that.