4 ms·
Internally it can store them as 16bit so strings have a fixed length
by excuse-me 14y ago
Internally it can store them as 16bit so strings have a fixed length
- deleted 14y ago[deleted]
- pjscott 14y agoDoes anybody really think that UCS-2 is a good idea anymore? Or that random indexability by code point is all that valuable, in a world with combining glyphs and bidirectional characters and whatever other crazy stuff Unicode has? If you just want an upper bound on the number of bytes needed to store n code points, then (a) that's probably not a particularly useful question to ask, and (b) if you assume that 32 bits is enough for any code point, then the space taken by properly-formed UTF-8 is bounded. So, why would they want to store things internally as UCS-2? Or rather, why should they?
- jeltz 14y agoWhich is in many cases not faster than UTF-8 since UTF-16 is often more bytes than UTF-8. This matters especially since we are talking about a database which means IO and RAM usage probably are more important than the CPU.
- Dylan16807 14y agoExcept it didn't. It used up to three bytes per character. It had the drawbacks of variable width but not the easy-to-add benefits. Or do you mean in-memory being different from the file format AND different from the I/O format? That doesn't sound terribly efficient.
- deleted 14y ago[deleted]