Qt-interest Archive, September 1998
Be careful with QListIterator
Message 1 in thread
Hi,
in case your program is running too slow, you might want to check whether you
are using one of the iterators. I could speed up one function (data as measured
by Visual Quantify - if you are going to buy only one software development tool
this year, get this one...) 25 times (!) simply by replacing the usage of
QListIterator with simple calls to QList::first() and QList::next(). As
Quantify showed, the speed loss was mainly in the constructor and destructor of
the iterator.
Yes, I know that iterators are a good concept from a software design point of
view, but with this speed gain...
Hmmm, does this qualify as a bug? I send a report to qt-bugs just in case...
Kalle
P.S. One other thing that Quantify showed me: QString::sprintf(),
QString::left() and QString::mid() are very slow, too.
--
[ signature omitted ]
Message 2 in thread
Hi,
On Fri, 11 Sep 1998, Kalle Dalheimer wrote:
> Hi,
>
> in case your program is running too slow, you might want to check whether you
> are using one of the iterators. I could speed up one function (data as measured
> by Visual Quantify - if you are going to buy only one software development tool
> this year, get this one...) 25 times (!) simply by replacing the usage of
> QListIterator with simple calls to QList::first() and QList::next(). As
> Quantify showed, the speed loss was mainly in the constructor and destructor of
> the iterator.
>
> Yes, I know that iterators are a good concept from a software design point of
> view, but with this speed gain...
>
> Hmmm, does this qualify as a bug? I send a report to qt-bugs just in case...
Well, it is just a question if implementation. STL Iterators are
damn fast. Perhaps a bit slower the first and next, but more powerful.
QListIterator is indeed slow. I assume it is becuase of its
error checking. STL iterators do not a single error check.
So you must know what you are doing :-)
Bye
Torben
> Kalle
>
> P.S. One other thing that Quantify showed me: QString::sprintf(),
> QString::left() and QString::mid() are very slow, too.
>
>
> --
> Kalle Dalheimer Contract programming for Unix
> kalle@dalheimer.de Technical writing
> kalle@kde.org Technical editing
> kalle@oreilly.de KDE Developer (MFCH)
> mdalheimer@acm.org It's open, it's source, it runs - must be KDE!
>
>
> --
> List archive and information: http://www.troll.no/qt-interest/
>
Message 3 in thread
weis@stud.uni-frankfurt.de
> QListIterator is indeed slow. I assume it is becuase of its
> error checking. STL iterators do not a single error check.
> So you must know what you are doing :-)
It's more likely to be because they're "real" function calls, not
inlines as in the STL. On modern CPUs making a function call is much
more expensive than older ones, as the cost of pipeline breaks and
cache misses keeps going up.
We could have made them inline, but then we'd have bloated Qt and
gained very little by it.
(For a library programmer, who knows that most of the code only needs
to keep up with e.g. the speed people can click the mouse, but that
all the code will be pulled into RAM on a great many machines, it
generally makes sense to optimize for size rather than for speed.)
--Arnt
Message 4 in thread
> > QListIterator is indeed slow. I assume it is becuase of its
> > error checking. STL iterators do not a single error check.
> > So you must know what you are doing :-)
>
> It's more likely to be because they're "real" function calls, not
> inlines as in the STL. On modern CPUs making a function call is much
> more expensive than older ones, as the cost of pipeline breaks and
> cache misses keeps going up.
>
> We could have made them inline, but then we'd have bloated Qt and
> gained very little by it.
Oops, still wondering, I thought the compiler does inline optimization alone if the functions are small
enough ? Perhaps I have to point out that I am working on SGI, so I don't know if this is right for other
plattforms.
> (For a library programmer, who knows that most of the code only needs
> to keep up with e.g. the speed people can click the mouse, but that
> all the code will be pulled into RAM on a great many machines, it
> generally makes sense to optimize for size rather than for speed.)
But sometimes there are applications which use very huge data stuff, so there's the need to optimize for
speed. For example I am writing a little scene graph editor for a graphic package and my users would
kill me if it takes significantly longer compared to other programms.
Maybe there would be the possibility to add a preprocessor macro which enables he user to optimze for
speed. Default could be of course not optimizing for speed.
Matthias
begin: vcard
fn: Matthias Stiller
n: Stiller;Matthias
org: Fraunhofer Institute for Computer Graphics
adr: Waldstr. 1;;;Muenster;;64839;Federal Republic of Germany
email;internet: stiller@igd.fhg.de
tel;work: n.a.
tel;home: +49 - 6071 - 35043
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard
Message 5 in thread
Matthias Stiller <stiller@igd.fhg.de>
> Oops, still wondering, I thought the compiler does inline
> optimization alone if the functions are small enough ?
Most compilers do, if they can see the function implementation and the
function call at the same time (ie. both are in the same .cpp file, or
the implementation is in an included .h file).
> But sometimes there are applications which use very huge data stuff,
> so there's the need to optimize for speed.
Absolutely. In which case you really need a profiler. If you're
using QListIterator or sprintf() and it's hurting your performance, a
profiler will point that out.
> Maybe there would be the possibility to add a preprocessor macro
> which enables he user to optimze for speed. Default could be of
> course not optimizing for speed.
I don't think so. That would be extremely difficult, and moreover be a
poor substitute for profiling. There are many better things to do.
--Arnt
