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

[Smith Martin]

>You are talking about a specific code path in qdoc, while this thread is about
>QList in general. This does not help at all.

But that was the point. The argument is that QList<C> should not be used at all, but in the specific code path where it is being changed, it was ok.

And apparently QVector has the same API as QList now, so why don't we deprecate QList. Let it always create a QVector.

martin


________________________________________
From: milian on behalf of Milian Wolff <milian.wolff at kdab.com>
Sent: Friday, July 10, 2015 3:22 PM
To: Smith Martin
Cc: development at qt-project.org; Giuseppe D'Angelo
Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Friday 10 July 2015 12:48:26 Smith Martin wrote:
> >Calling malloc/free is not a cheap operation, when you profile most Qt
> >applications, you'll find these functions nearly always in the top 10,
> >often even the top 5, of functions where most time is spent.
>
> But, Marc made QVector for QList swap in qdoc several weeks ago for the same
> kind of thing, but I couldn't see any difference in the run time for qdoc.

Try perf stat, but even then maybe the impact is not high. But if we'd do it
everywhere, the overall performance goes up. Bad performance is often a "death
by a thousand cuts".

> >Huh?! I really don't follow your reasoning to both of these points here. I
> >suggest you go watch https://channel9.msdn.com/Events/Build/2013/4-329
> >and similar talks out there to educate yourself? Whenever you
> >access/traverse a list of pointers, you'll incur cache misses, except in
> >the rare case where you are lucky and the pointers point to contiguous
> >memory locations. And even then, you'd have an indirection that Peppe
> >mentions.
>
> In this case, qdoc creates a QList<ParsedParameter> as it parses a function
> signature. All the calls to malloc occur one right after another, and then
> the list is complete. There hasn't been any intervening heap work, so all
> these ParsedParameters will be sequential and will be allocated right after
> the QList itself.

This is not necessarily true. Malloc implementations are free to return random
pointers. Maybe you are lucky and the stuff is sequential, most probably not.
And you'd still have the indirection. Also, maybe it's not a big deal for this
one specific use case, but in the general usecase you have other allocations
inbetween the list appends, thereby rendering your above reasoning invalid.

> But more importantly, this was just a temporary mechanism to correct the
> parsing of friend function declarations, which broke in qdoc, because good
> old Marc started making friend functions be friend inline functions with
> the body defined in the friend inline declaration inside the class. I think
> Marc's goal is to be the first ever software engineer to use every possible
> combination of C++ features. Still, this one is certainly legal, but qdoc
> couldn't handle it (qdoc still doesn't have a real C++ parser *** see
> below***), so I rewrote the function that parses function declarations so
> that it waits to create the list of parameters until it knows whether it
> should create the function node in the first place.
>
> This QList<ParsedParameter> was meant to be a temporary solution, because
> that list gets copied into a QList<Parameter> if qdoc finally decides to
> create the function node. That, of course, is inefficient, but I generally
> don'[[t try to optimize until I have a working model.

You are talking about a specific code path in qdoc, while this thread is about
QList in general. This does not help at all.

Bye

> > >2) you make the compiler produce more inefficient code by introducing
> > >the layer of indirection;
> >
> > But it will process the list one time only, from beginning to end.
> >
> > >3) you kill caching, as potentially every single access will result in a
> > >cache miss (even in the common scenario of a simple forward iteration
> > >over your list);
> >
> > Why? All the entries in the list are created at the same time (well,
> > during
> > the parsing of the function signature)
>
> Huh?! I really don't follow your reasoning to both of these points here. I
> suggest you go watch https://channel9.msdn.com/Events/Build/2013/4-329
>  and similar talks out there to educate yourself? Whenever you
> access/traverse a list of pointers, you'll incur cache misses, except in
> the rare case where you are lucky and the pointers point to contiguous
> memory locations. And even then, you'd have an indirection that Peppe
> mentions.
>
> 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

--
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