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

List:       kde-devel
Subject:    Re: Two optimization questions
From:       Michael Pyne <pynm0001 () comcast ! net>
Date:       2004-04-21 0:30:51
Message-ID: 200404202030.56967.pynm0001 () comcast ! net
[Download RAW message or body]

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

On Tuesday 20 April 2004 17:23, Adriaan de Groot wrote:
> [Perhaps better for kde-optimize, I know, although these questions are
> mostly code-clarity vs. extremely minor performance gains.]
>
> (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?

It's one of those things that depends on the implementation.  I haven't looked 
at Qt's implementation of it, but if the end() call simply returns a 
constant, there's really no difference.  If the end() call has to look for 
the end of the container, then it makes more sense to do (2).

BTW, I actually find (2) more readable anyways, at least if e was named a 
little more descriptively. ;-).

> (2) Consider function foo(), which spans 96 lines (that's 4 screenfuls). It
> consists of several identifiable blocks of functionality, so I _could_
> write it like
>
> 	T foo() { doThis(); doThat(); doItWithAWhiffleBallBat(); doRest(); }
>
> 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?

You have the right idea by declaring it static.  The symbol won't get exported 
that way, unless it is a member function of a class.

If you also declare it inline, the compiler has the option of inlining it.  
AFAIK, the only reason a compiler wouldn't is because A: You told it not to 
(-fno-inline for GCC), B: You took the address of the function, and C: I 
forgot :-).

Regards,
 - Michael Pyne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAhcC/qjQYp5Omm0oRAv6XAKCho69emlIjzOjVgjRm6ywSQpGa8ACgw+i6
RGrgzb5E4MuPUHIz7Jc6I/Q=
=+D3H
-----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]