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.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
