[Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Tuesday 19 January 2016 17:43:59 Matthew Woehlke wrote:
> On 2016-01-19 05:51, Marc Mutz wrote:
> > So... is realloc actually the optimisation everyone (incl. me) expected
> > it to be?
> 
> It really *ought* to be, at least in the right cases.
> 
> Let's say I have a type that stores a buffer, which, for whatever
> reason, is not movable (i.e. no move-ctor or swap¹), but *is*
> relocatable. Resizing a vector of such types involves allocating the new
> block, doing a single block memcpy, and releasing the old block.
> 
> Resizing if they were *not* relocatable involves a copy ctor for each,
> which involves allocating a new memory block, copying the data, and
> releasing the old block *per item*, plus the two memory operations
> 
> If 2*N heap operations plus N block copies of "large" blocks are
> comparably expensive to a single block copy of N*sizeof(void*), I would
> be very surprised :-).
> 
> (¹ Keep in mind also that the move/swap quite possibly must also be
> noexcept or it can't be used anyway.)
> 
> Maybe we're looking at bad examples, or there are fewer such instances
> than expected where it is significantly better. (In particular, I
> suspect neither string nor QByteArray are "good examples". Try with a
> type that always allocates memory?)

0.736s for QVector<QEasingCurve>
0.787s for std::vector<QEasingCurve>
0.682s for QVector<QEC> with reserve() called
0.670s for std::vector with reserve() called

Which means that the realloc()s cost 54ms and the re-allocations + moves cost 
117ms. Meaning 2×. It also means that if you can reserve(), all that 
optimisation gains you ... nothing.


-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts