>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. >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. 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. *** If anyone wants to explain how I can use the Creator clang C++ parser in qdoc, I could get started on that upgrade to qdoc. It's a big job I don't want to start until I know it makes sense. martin ________________________________________ From: milian on behalf of Milian Wolff <milian.wo...@kdab.com> Sent: Friday, July 10, 2015 2:04 PM To: development@qt-project.org Cc: Smith Martin; Giuseppe D'Angelo Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO On Friday 10 July 2015 11:35:34 Smith Martin wrote: > >1) you put pressure on the memory allocator, by asking it to allocate on > >the heap each individual C object you put in the list. Every single > >allocation has a cost, plus the overhead you need for bookkeeping, plus > >the costs of getting your memory fragmented, etc.; > > This pressure on the memory allocator, what is that? My memory doesn't get > fragmented, because I only build lists; I never destroy them. But I do have > to put each C somewhere, and if I use QVector<C>, doesn't it allocate a lot > of them up front? I don't know how many i will need, but the number is > usually 0, 1, or 2 -- the number of parameters in a function signature. 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. > >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.wo...@kdab.com | 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
