On 21 Aug 2019, at 17:55, Thiago Macieira <thiago.macie...@intel.com> wrote: >> That's why we are not removing QLatin1String: the Latin1 algorithm is >> as fast as memcpy. The only thing better than that is zero copies.
Lars Knoll (22 August 2019 13:42) replied: > We could also turn this around: Are we over-optimising here? Do we > have the right balance between ease of use and performance? Converting > utf8 is a bit more costly than latin1, but would that ever matter in > real world use cases? I guess that's a matter of how much of a performance penalty you're willing to pay. If you look at qtbase/src/corelib/codecs/qutfcodec.cpp you'll see it's all very non-trivial - and makes heavy use of functions that are heavily optimised to exploit particular instruction sets to squeeze all the boosts they can into the performance. It's highly complex and I won't pretend to understand it. That's the UTF8 path Thiago is talking about. There is no short-cut, although I do wonder why there isn't a "search for the first byte whose top bit is set", which might equip us with one. The QLatin1String path is essentially qt_from_latin1() in qstring.cpp; 50 lines of code, vs several hundred; it does have some fancy optimisations to exploit special CPU instructions; but one of its #if paths really is just while (size--) *dst++ = (uchar)*str++; i.e., as Thiago said, essentially (except for *dst being bigger than *str) memcpy(). The other code paths are ways to optimise that. The latter is obviously way cheaper than the former. Is that a price you're willing to pay, throughout all our library code, for ease of writing library code ? Eddy. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development