On 29 March 2017 at 12:49, Marc Mutz <[email protected]> wrote: > This is probably one of the most important things. Ville asked on std- > proposals to show hard numbers. You don't need hard numbers. You just need to > superficially look at QVector<QString>. The compiler generally cannot proove > that the call to QArrayData::deallocate() can be dropped from the QString > dtor. It will always emit the atomic lock;sub and the call to deallocate(), > even though the move ctor is inline and sets the d-pointer to sharedNull(). I > have tried many things over the past year or so, incl. Q_ASSUME(!ref == -1) in > sharedNull() and explicitly checking for that same condition in the QString > dtor. It just doesn't help. > > This is an example of the WTF missed-optimisation that Chandler presented at > MeetingC++ 2016: https://www.youtube.com/watch?v=s4wnuiCwTGU > > Only difference: we need it for thousands of items, not just four.
The hard number we still need is this: 1) how much of a performance difference does a destructive move make The softer numbers we need are these: a) how many types benefit from it b) how often are those types used c) what are the practical performance improvements, assuming that the hard number (1) gave us a benchmark number. If "you don't need hard numbers", be prepared to live with a C++ that doesn't have a destructive move. Assuming that everyone in the committee finds its motivation obviously sound is a losing strategy, as is assuming that many people in the committee are aware of how destructive move helps implicit-sharing containers. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
