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

List:       kde-devel
Subject:    Re: Two optimization questions
From:       "Andrew Coles" <andrew_coles () yahoo ! co ! uk>
Date:       2004-04-20 22:16:34
Message-ID: 00be01c42725$24629450$1530a8c0 () parkle
[Download RAW message or body]

> (1) Consider
>
> for (QStringList::constIterator i = l.begin() ; i!=l.end(); ++i) { .. }
>
> versus
>
> QStringList::constIterator e = l.end();
> for (QStringList::constIterator i = l.begin() ; i!=e; ++i) { .. }
>
> Is there really a big performance hit for the first?

In this case - not really, as the end() function is quite cheap so even
though it is called each time round the for it doesn't cause much delay.  If
it's the length of a C string, though, it does add up (the C string length
loops through the string until a character 0).

I think, if my understanding of optimisation theory is correct, if you do

const QStringList::constIterator e = l.end();
for (QStringList::constIterator i = l.begin() ; i!=e; ++i) { .. }

it is potentially faster; even if it isn't you may as well do it, unless you
plan to reuse e later on, as it is another useful safety.

With regards it being harder to understand - not sure, if you keep it on
adjacent lines I'd say it's as near as makes no odds; and, in either case,
QT 4 has a foreach construct which will hopefully wrap this one up.

> What's the performance hit here? I'd hate to have real function-call
overhead
> for those functions, and I'd hate for them to be external symbols, since
> they'd slow down linkage to no effect. Can I count on the compiler to
inline
> these in foo?

If you make the explicitly inline they will be inlined unless you
do -fno-inline as far as I know.  You can (although I forget how) set the
extra functions so their symbols are not exported, i.e. can only be used in
the same compile context.  If that fails, define them as preprocessor macros
:-)

Hope that helps,

Andrew

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]