On terça-feira, 31 de janeiro de 2017 18:39:43 PST Marc Mutz wrote: > Q6String will likely have the small-string optimisation, so short strings > aren't actually COWed, but deep-copied. Passing through QStringView then is > about the same efficiency as passing through a const QString&.
Not sure you can count on this optimisation. Even my expanded QString is only 24 bytes on 64-bit, which means that you can store floor((24 - 1) / 2) = 11 characters in the short string. I don't have my data ready here, but when I calculated the histogram for qHash, 22 bytes was very far from the overwhelming majority of the strings (I remember 34 bytes was a significant mark, I just don't remember if it was 75% or 90%). My current QString for 32-bit is only 12 bytes, which gives us 5 characters at most. That's definitely more overhead than the potential gain. It would be better to expand it to 32 bytes, even on 32-bit platforms. That's 15 characters and can be implemented by two SSE moves (or one AVX) on x86, versus one SSE plus one GPR on 64-bit or three GPR moves on 32-bit. That implies we need to expand QVariant to 40 bytes. Fortunately, we don't plan on keeping QList the way it is, or it would suffer greatly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
