[Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Sean Harmer sean.harmer at kdab.com
Mon Feb 9 15:56:28 CET 2015


On Monday 09 Feb 2015 09:49:08 Marc Mutz wrote:
> On Monday 09 February 2015 09:32:56 Marc Mutz wrote:
> > > Something like this should work just as well on QVector, right? If you
> > > are doing multiple inserts, perhaps you should keep the inserts outside
> > > the main vector while you make them, and only at the end do a single
> > > std::merge.
> > 
> > Boom. Enter quadratic behaviour.
> > 
> > There is Loki::AssociativeVector, but things like the above is why no-one
> > is  using it. You only gain if you don't contantly maintain the is_sorted
> > invariant.
> 
> To make my statement more precise: As soon as you provide insert_sorted, the
> same people who now use QSet + toList + sort() will invariably use it in a
> loop.
> 
> Using a plain vector *is* fine. One just need to get over the fact that this
> is not Python and one has to use std algorithms and function objects.
> 
> It's not the syntax that's a problem. It's the semantics that need to be
> understood. In this case, *both* algorithmic complexity *and* the cost of
> non- locality of reference (which is why QMap is so bad).

I guess depending upon the sizes of your key and value types and number of 
elements and typical frequencies of operations (inserts vs lookups vs 
removals) it may also possibly be better to use two vectors, one for the keys 
and one for the values.

The rationale being that if your value type is large you reduce the number of 
key values that can be stored in a cache line and therefore incur more cache 
misses when performing lookups. Of course you would still incur at least one 
cache miss when loading in the value to return.

It's surprising just how expensive cache misses are these days compared to 
traditionally thought-to-be-expensive CPU instructions.

Anyway, if somebody does implement a nice wrapper around such sorted vectors 
with sufficient controls to force/not-force the sorted invariant to allow 
efficient insertion/removal vs efficient lookups, we have a ton of places in 
Qt3D where you could test such a beast. :)

Cheers,

Sean

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions



More information about the Development mailing list