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

[Sean Harmer]

Hi,

On 12/07/2015 18:56, Smith Martin wrote:
>> If it doesn't, then why not choose QVector?
> My intent in getting the information from Marc is to change the documentation of QList to say that.
>
> But QList is easy to use.

Given the API is almost identical, so is QVector. Also having been shown 
that QVector performs better than QList, both in the general case and 
the majority of cases, both in terms of performance and memory 
efficiency, what other information do you require specifically?

With respect to your argument about changing the high level algorithm 
having more effect than a QList to QVector switch, that is no surprise. 
Altering algorithms at that level often has a more profound effect. 
Changing QList to QVector after such a change will yield a small benefit 
but expecting it to be comparable is unreasonable. For a fun 
visualisation of the access speeds of the various cache levels take a 
look at this little animation 
http://www.overbyte.com.au/misc/Lesson3/CacheFun.html

As Andreas pointed out, if you can avoid any memory allocations at all 
in performance critical sections that is good, but having the memory you 
work on being located in contiguous regions is as good as it is possible 
to get with today's hierarchy of cache architecture. There's a nice 
illusatration of how changing the high-level algorithm _and_ ensuring 
that your data is located in contiguous yields good results and 
importantly, _why_ it gets good results. Although it's written in the 
context of the PS3 it's also relevant to other architectures too. It's 
available at:

https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCEQFjAAahUKEwiwpJWxmtbGAhVlgdsKHYR_Ciw&url=http%3A%2F%2Fharmful.cat-v.org%2Fsoftware%2FOO_programming%2F_pdf%2FPitfalls_of_Object_Oriented_Programming_GCAP_09.pdf&ei=vq-iVbDNIeWC7gaE_6ngAg&usg=AFQjCNEZ1HUlVbU83BDYfyJw5mfdOob8iw&sig2=mT486mHb0Va1eYz7smn6-w

QList is one of the culprits that leads to death by 1000 paper cuts. 
That is, when your app doesn't run as fast as it should but there is no 
one single big hitter in the profiling data as the problem is diffused 
across the entire application.

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