> On 2 Nov 2018, at 04:45, Thiago Macieira <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
