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

List:       kde-devel
Subject:    Re: The no goto religion
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2007-07-30 15:04:21
Message-ID: 200707300904.25651.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 30 July 2007, James Richard Tyrer wrote:
> David Capel wrote:
> > On 7/29/07, James Richard Tyrer <tyrerj@acm.org> wrote:
> >> James Richard Tyrer wrote: Since on a pipelined processor, a jump
> >> is a very expensive instruction, it is best to avoid unneeded jumps
> >> if possible.
> >
> > That is a micro-optimization, at best.
>
> More like peephole optimization.
>
> > You always should test and profile code before doing such silliness.
>
> Profiling is used for macro-optimization, it has no place in peephole
> optimization.

the issue is that such optimizations often make the code less readable, which 
leads to maintenance issues. so unless the optimization results in meaningful 
improvements in speed, then it isn't worth it.

the goto patch saves one check to icon.isValid(), which happens to contain 
this one line of code:

	return size != 0;

size is an int. 

the code you reference is in loadMovie which gets called aprox 0 times in the 
lifespan of a kde session.

so ... your optimization nets us not much while making the code more brittle 
and difficult to maintain in the future.

> I see nothing silly about using good coding practices based on the
> elimination of redundant code.

agreed, except using goto here makes the code less readable and more prone to 
future errors, e.g. someone inserting code between the two fors now has to 
remember to do a goto if the icon is found; each block is no longer 
self-documenting as to its purpose (finding an icon if we don't have one) and 
guaranteed to continue to work if the surrounding context changes.

> > Coder time is more important (and expensive) than CPU time 99.999% of
> >  the time, and desktop applications will only very rarely fall into
> > the other category. So unless you are writing crazy kernel code or
> > some other time-critical piece, favor readability.
>
> I think that my changes also improve readability.

taste and maintenance expectations differ, i suppose.

> a lot -- in case you didn't get the memo, KDE code is slow.  However, in

are there places for optimizations? you bet. but those optimizations are 
primarily of the "better algorithm" and "stop hitting disk so much" 
and "don't wake up the cpu more than necessary" variety. 

> this case, fixing a bug eliminates the issue. 

what was the bug?

> But, that doesn't mean 
> that sloppy coding is acceptable just because something hasn't been
> profiled.

i don't see the sloppy code in your example. adding optimizations to code 
where it is irrelevant to running times is not good form, however.

> You might want to read an assembler listing if you aren't familiar with
> how to write such a function in assembler.  Remember, machine language
> code isn't structured -- it is full of 'goto's.

... and that's why we don't write in assembler but use a higher level 
language.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

[Attachment #5 (application/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]