[Development] Qt6 source changes
Lars Knoll
lars.knoll at qt.io
Fri Nov 2 09:43:56 CET 2018
> On 2 Nov 2018, at 04:45, Thiago Macieira <thiago.macieira at intel.com> wrote:
>
> On Thursday, 1 November 2018 19:18:11 PDT Kevin Kofler wrote:
>> Thiago Macieira wrote:
>>> We're studying what to do with QList, but the idea is that the name
>>> "QList" will be completely ok and identical to QVector. The technical
>>> mechanism is in flux.
>>
>> That means you will be pessimizing element inserts and removals from O(n) to
>> O(mn), where n is the length of the list and m the size of each element,
>> without offering a good alternative without that pessimization (sure, you
>> can use a QVector<T*> or QVector<SomeSmartPointer<T>>, but those have
>> somewhat different semantics and less convenient syntax).
>
> Yes. Is that a widespread use? And will it be a perceptible change?
>
> Don't forget that m is a constant, for any given list. It's not a scalability
> problem, since no matter how many inputs the user provides, the size of the
> object will not change.
m is basically the size of the object. So for pointer sized objects it doesn’t make a different. For large objects QList actually also has an overhead, namely the malloc() incurred for each item inserted.
I’ve tried a bit and for most use cases where the list and the object are of reasonable size (e.g. 4*sizeof(ptr)and ~100 items in the list) that overhead is actually just as large.
>
>> It won't make a difference for implicitly-shared objects (but QList already
>> works like a vector for those anyway), but for large in-place objects, it
>> can make a big difference.
There are always use cases where it can make a difference. The question is what happens for most use cases (ie. 90 or even 95% of the cases)? And based on my measurements so far, I’d say we will see a performance improvement for those, leading to an overall improvement.
Cheers,
Lars
More information about the Development
mailing list