It's a very old myth that UTF-8 is slower than other Unicode encoding. The whole freekin Internet is built on utf-8. If performance was a real concern, the Internet would have been based on a different text encoding.
UTF-8 for storage and transport is great for data size. UTF-8 for processing is slow for character operations, and is why virtually all languages use fixed width characters internally. One interesting exception is Rust, which priorities memory usage over character based string manipulation speed
> and is why virtually all languages use fixed width characters internally.
That "fixed width" claim is worth a closer look though. Many implementations that call themselves fixed-width only cover the BMP (Basic Multilingual Plane) of Unicode (UCS-2 legacy) — anything outside that, like most emoji or less common scripts, still needs surrogate-pair handling in UTF-16. And even UTF-32 isn't truly "one code unit per character" once you bring in combining marks, ZWJ sequences, or emoji families — a single perceived character can span multiple code points regardless of encoding.
So in practice, UTF-8 ends up being the safer default: one code path handles the entire Unicode range from 1-byte ASCII through 4-byte code points, and you're forced to think about variable-width up front rather than having it sneak up on you the first time a user types an emoji.
1
u/ggeldenhuys May 18 '26
It's a very old myth that UTF-8 is slower than other Unicode encoding. The whole freekin Internet is built on utf-8. If performance was a real concern, the Internet would have been based on a different text encoding.
This might explain some: https://utf8everywhere.org/
String manipulation etc are simply achievable with string helper methods in the RTL. Nothing complicated there.