[Development] Wishes for C++ standard or compilers

[Thiago Macieira]

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