[Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Milian Wolff milian.wolff at kdab.com
Sun Jul 12 16:06:20 CEST 2015


On Sunday, July 12, 2015 04:58:01 PM Marc Mutz wrote:
> On Sunday 12 July 2015 15:05:51 Gunnar Roth wrote:
> > Hi Marc,
> > 
> > > Better provide a benchmark into which users can easily plug their own
> > > types and that plots relative performance of various containers at
> > > various sizes. Then they can use that on their platform, on their type,
> > > with their access patterns to determine which container to choose.
> > 
> > I tried to write a container benchmark for testing qt , std and boost
> > containers. I did that already a while ago, but had not collected enough
> > energy to post about it until now . ;-) This is not including QList
> > because the benchmark is made to test how fast i can lookup something in a
> > container.
> > 
> > It can be found at https://github.com/gunrot/qtcontainerbench
> > <https://github.com/gunrot/qtcontainerbench> I got irritating results from
> > it , concerning all the praise i read on the qt mailings list for Vector
> > instead of map or hash.
> 
> That's because your benchmark runs entirely in L1.
> 
> If you want to test containers of 10, 100, 1000 and 10000 elements each,
> then make
> - one run over 1×N containers of 10000 elements each,
> - one run over 10×N containers of 1000 elements each,
> - one run over 100×N containers of 100 elements each,
> - one run over 1000×N containers of 10 elements each.
> 
> You need to use a working set size large enough to not hit L1 all the time,
> because it's just not the usual case that a lookup table is completely in
> L1. But you can start with a small working set. As you increase the working
> set size, you should see how each individual test (at constant number of
> elements) increases in runtime. And you will see that the contiguous
> containers don't loose as much as the node-based.

<snip>

In addition to that, you should additionally benchmark the setup cost for the 
containers. I have often seen code that was slow, not because finding items in 
it was slow, but rather because the lists where temporary and thus the setup 
cost never amortized. Then, the cost of malloc & free is significant, often 
orders of magnitude more expensive than actually finding the elements. There, 
QVarLengthArray (if possible) or at least QVector/std::vector _really_ shines.

Bye
-- 
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/20150712/8697db4f/attachment.bin>


More information about the Development mailing list