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

List:       kde-devel
Subject:    Re: "Fixed" post-increment operators on iterators
From:       Benjamin Meyer <ben () meyerhome ! net>
Date:       2004-11-01 15:29:00
Message-ID: 200411011029.04693.ben () meyerhome ! net
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 01 November 2004 5:31 am, Richard Smith wrote:
> 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.

Over on the kde-optimze list someone did some profiling and found there to be 
a noticeable improvement just by changing the i++ to ++i
 
http://lists.kde.org/?t=109828707000001&r=1&w=2&n=18

Also I have put together a little test app in 
kdenonbeta/kdetestscripts/compilertests/ where I show that using const would 
give even more improvement.

Feel free to play with it and make your own conclusions.

- -Benjamin Meyer

- -- 
aka icefox
Public Key: http://www.icefox.net/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFBhlZA1rZ3LTw38vIRApiSAKCgw6H3OyyOzufinUm/i6grzF1ULgCgnbre
fIy8lrrr2q5p9kBQRjrRr+U=
=uA1Q
-----END PGP SIGNATURE-----
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]