Il 28/04/20 11:16, Kevin Kofler ha scritto:
* or the SSO gets reverted.
It's not SSO.
Is there any actual evidence that it is a win in practice?
Yes. But it's not SSO.
And on what hardware?
Enough to justify the adoption in all std::string implementations and in 3rd party ones as well (e.g. Folly).
It is very hardware-dependent whether copying several bytes is faster than incrementing one atomic. That may well be the case on today'shardware, but what about tomorrow's?
Even more.
And what about older hardware that is still in use?
Right, let's establish the foundations for the Qt 6 lifetime (2020-2035) by looking at 2002 hardware.
The rule of thumb should be that copying less is better than copying more.
But: is copying less AND allocating better than just copying more?
The confirmation bias comes from the fact that Qt datatypes are designed to work nicely with QList; this for at least two good reasons: a) Qt value types are normally pimpled (because of refcounting, or ABI stability) so they fit exactly in QList's array slots, but user-defined types aren't necessarily pimpled. Thus the bet: they're almost always the wrong size for QList. b) We've spent an awful amount of time reviewing Qt's source code and tagging down every value type as movable (where it made sense). And I'd like to extend a big thank you to Sérgio for clazy, Marc for tirelessly fixing the code, Thiago for giving us relocatable types before Qt 6 in QVector-but-not-QList-as-that's-BIC. Users simply forget the dreaded typeinfo macro and so, for their types, QList is always in array-of-pointers mode no matter the size of the datatype.I use implicitly-shared types and Q_MOVABLE_TYPE annotations in my code.
Good.While we're at empirical evidence, do you want evidence of the contrary? Endless other users don't. Qt examples contain several instances of QList<Foo> with Foo untagged and too big to fit anyhow.
These can also usually be added later when needed. User code is not bound by as strict binary compatibility rules as Qt itself.
Can be != will be. Those examples have been around for a decade.
In conclusion, if QList is a good choice for Qt's own types, and even if we then expose it at the API level as the Qt container of choice, its only advantage then over QVector is going to be prepending? How often is that a use case to justify the semantic burden of this extra container?The prepending optimization alone is a necessary feature. Replacing QList with an unmodified QVector, without that prepending optimization, is entirely unacceptable.
And the evidence for this need is?
This cannot be claimed as a closed result: for insertion, it's ignoring the cost of the individual allocation of the newly inserted item, that needs to be traded off the moving of more bytes in memory.That is highly dependent on the hardware, the operating system, and the malloc implementation (where there is more than one for the operating system). So the results you obtain will depend on what you run the benchmark on.
That's why I didn't provide numbers, but still pointed out that the result, alone, is wrong.
-- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
