[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: "Fixed" post-increment operators on iterators
From:       Richard Smith <kde () metafoo ! co ! uk>
Date:       2004-11-01 10:31:16
Message-ID: 200411011031.16379.kde () metafoo ! co ! uk
[Download RAW message or body]

On Sunday 31 October 2004 18:32, Aaron J. Seigo wrote:
> On Sunday 31 October 2004 05:27, Esben Mose Hansen wrote:
> > On Sunday 31 October, 2004 12:59, Frederik Schmid wrote:
> > > > QStringList::ConstIterator itEnd = matches.end();
> > > > for(QStringList::ConstIterator it = matches.begin(); it != itEnd;
> > > > ++it) _keyList->insertItem(*it);
> >
> > [...]
> >
> > > The compiler will (almost certainly) move loop-conditions out ouf the
> > > loop, so no need to add extra lines in this case.
> >
> > I have always wondered about that. Unless the container is const, how can
> > the compiler know that mycontainer->end() always returns the same value?
>
> exactly, and so it won't, and so caching the return value of end() (or
> length(), or...) almost always results in a speedup (of how much and of
> what impact is another matter)

As it happens, end() is very often inline, so the compiler can sometimes know 
that the value of end() does not change. For a QPtrList where end() is inline 
and always returns 0, caching end() in the way described above could cause 
the compiler to forget that, and could actually cause the loop to be slowed 
down.

For a QValueList (and therefore for a QStringList) caching end() is more 
likely to gain you some speed, but probably not much more than one memory 
lookup per iteration. Is that worth more code and more of your time?

A much better improvement (especially for the code above) would be to 
change .begin() to .constBegin() and .end() to .constEnd() wherever possible.

I don't see why such effort is being made here; a possible marginal 
optimisation (no-one's claimed to have done any profiling yet; these changes 
might be detrimental in some cases) of a loop over a list of maybe a few 
dozen elements which is only run very rarely will not improve the general 
speed of KDE. I'd be surprised if there was *any* noticable speed change. If 
something is too slow, profile it, find where it's slow, and optimise there. 
Otherwise, don't waste your time.
-- 
Thanks,
Richard
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]