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