On quarta-feira, 29 de março de 2017 02:53:16 PDT Ville Voutilainen wrote: > The hard number we still need is this: > 1) how much of a performance difference does a destructive move make
QVector<QString> is all you need to see that. Without destructive moves: 1) allocate new block 2) move each element (constructor is noexcept, good) -> could be a memcpy + memset, but isn't... 3) destroy each element (refcount is checked every time!) 4) deallocate the old block With destructive moves: 1) allocate new block 2) destructive-move every element (a memcpy, whether explicit or not) 3) deallocate the old block With trivial destructive moves: 1) realloc Do we need to actually benchmark this? > The softer numbers we need are these: > a) how many types benefit from it $ git sgrep -E 'Q_DECLARE_TYPEINFO.*Q_(MOVABLE|PRIMITIVE)' | wc -l 442 > b) how often are those types used QString and QByteArray are among them, so extremely often. > c) what are the practical performance improvements, assuming that the > hard number (1) gave us a benchmark number. See above. > 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. Ok, so I guess we can easily benchmark this by making the Qt containers forget about the movable property, then benchmark the load time of a large application like Qt Creator. Unfortunately, this means recompiling everything, since containers are inlined everywhere. It's easy (a two-line change in qtypeinfo.h), but takes times. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
