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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
