[Development] Question about QCoreApplicationData::*_libpaths

Milian Wolff milian.wolff at kdab.com
Thu Jan 21 14:15:49 CET 2016

On Donnerstag, 21. Januar 2016 05:44:05 CET Kevin Kofler wrote:
> Bubke Marco wrote:
> > So you optimized the container for growing with allocations. I don't think
> > it is the most common case. Having cache misses in traversing the
> > container can be much worse and is much harder to fix than a reserve.
> Almost all my containers grow with allocations. How should I know in advance
> how much memory to reserve? It'd just waste an arbitrary amount of memory
> and then still end up reallocating because it'll inevitably be exceeded at
> some point. Variable-size containers are variable-size for a reason.
> I consider reserve() to be a technical detail and a micro-optimization I
> really should not have to bother with in 99+% of the cases.

This is very wrong. In my experience with profiling applications, the most 
hotspots can be fixed by adding reserve to loops where the size is known or 
can be guessed. This has a tremendous effect on runtime speed, also for 
QVector using realloc (remember: not doing something will always be faster 
than something, even if it's fast).

If you have code that adds elements from time to time and you cannot estimate 
the size, then I claim the speed of these operations is irrelevant anyways. 

Also note how calling reserve with an estimated value ("this vector usually 
has about N elements") fits into the usual memory/speed trade off: You may 
waste memory (improve your estimate!), but it's also much faster.


Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5903 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160121/5369af68/attachment.bin>

More information about the Development mailing list