Re: What "Unicode support" really means

On 05.03.14 14:50 , Pierre Joye wrote: > I do not think UTF-32 is even remotely an option. And both UTF-16 and > UTF-32 bring us back to the initial issue we had with the previous > unicode support attempt. UTF-16 is faster to process but the huge of > conversions (to and from) kill any performance gains, even worst, it > made php slower. UTF-8 is the only implementation that doesn't care about endianess, since it is just interpreted as a sequence of bytes. On the other hand a character can have 1, 2, 3 or 4 bytes, which makes length calculations more time consuming. It depends on what operations are mostly done internally, but I assume the engine itself uses rather basic input/output than substr, length or other more complex functions, thus UTF-8 might be the most performant approach. -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */