[Development] QList

[Marc Mutz]

On 2017-04-26 23:33, Alejandro Exojo wrote:
> On Wednesday 26 April 2017 07:02:49 Marc Mutz wrote:
>> FWIW: I'm against adding even more pessimising goodies to QVector. An
>> area for push_front is such a goodie. The addition this causes is
>> probably the reason why a QList, even for optimal payloads, is
>> outperformed by QVector in my well-known benchmark from -Wmarc. Users
>> that need a queue can use std::deque. If you don't iterate over it, 
>> it's
>> a more than acceptable container.
> 
> I'm afraid is not so well-known. The benchmark I know is found in:
> 
> https://marcmutz.wordpress.com/effective-qt/containers/

Yes, that was sloppy of me.

Of course, if you optimise for a use-case (like repeated prepends), then 
that use-case should benefit.

The fear I have is that, like in QList, this corner-case optimisation 
will pessimise the common case (appends, iterations). And I consider 
that not acceptable. If you need fast prepends, pay the price by using a 
std::deque (or a vector, or a vector with separate start/end indexes), 
but don't make every user of a vector pay for it. This is what happened 
in QList, which, to get to its begin(), needs to perform an addition 
(and, without having checked, two to reach its end()). And that's, I 
suspect, what makes QVector outperform QList even for QString payloads, 
as seen in, say, the first diagram in 
http://www.kdab.com/~marc/effective-qt/containers/results-append-tickcounter-linux_x86-64_473_gcc43-zoom-qt.html 
(uncheck all of QList/QVector).

Thanks,
Marc