Hello Currently QList is an array of void* and it stores items that fit that size and are movable in the array itself. This has a couple of inefficiencies:
- on a 64-bit platform, there's a 50% overhead for QList<int>
(QList<short> and QList<char> are unlikely)
- QList<double> uses indirect allocation on 32-bit platforms
- QVariant has one member of 12 bytes on all platforms, QSharedPointer and
QWeakPointer are always twice the size of void*, so QList of them always
uses indirect allocation (including QVariantList)
So I'd like to propose a change to QList's allocation strategy.
Option 1: large > 2*sizeof(void*)
- pros: will include double, QSharedPointer and QWeakPointer
- cons: does not include QVariant on 32-bit platforms, 75% overhead on int on
32-bit
Option 2: large > 16 bytes
- pros: includes double, the pointers and QVariant
- cons: overhead of 75% of int and pointers on 32-bit; 50% overhead of
pointers on 64-bit
Option 3: make it QList<T> be an actual QVector<T> for movable types, maybe
with an upper limit of size (32 bytes, 128 bytes?).
- pros: suitable for all types, shares code
- cons: more complex to implement, more code to compile and parse in headers
One big difference between QList and QVector today is that QList has prepend /
takeFirst optimisation, whereas QVector must move all elements to accommodate.
I would prefer if that optimisation remained present.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
