[Development] [SPAM] How bad QList really is

André Somers andre at familiesomers.nl
Tue Apr 28 06:06:29 CEST 2020


On 25-04-20 16:49, André Pönitz wrote:
> We all know the story that began with
>      "We knew for a long time that QList is not a good default
>      container, despite what the documentation claims. The problem
>      boils down to the fact that for a lot of types T, QList<T> is
>      needlessly inefficient by allocating elements on the heap and
>      storing pointers to them instead of storing the elements
>      in-place, like e.g. QVector does. Sometimes, for large and
>      complex types, that might be exactly what you want, but a
>      conservative estimate would put that chance at less than 5%." [1]
> I was curious how this "conservative" estimate of "less than 5%"
> manifests in real QList object instances in a real world example.
> My random picks of real world examples usually end up with "Loading
> the Qt Creator project in Qt Creator itself", and "statistics" is
> something I make up myself, in this case it is looking at QList objects
> at destruction time, and sorting them a bit according to size of
> the items in the list, number of items still present at that time etc.
> Besides being simple to do it's rather close to the typical use I see,
> where containers are filled up, accessed/used a few times and destroyed
> without much intermediate size changes.

Wouldn't you think that by now most cases where QList was *not* great to 
use have been replaced in QtC already, exactly because it's downsides 
have been known for quite a while now? I am going to assert that will 
skew your statistics, and thus make it basically impossible to draw any 
kind of conclusion from them.


More information about the Development mailing list