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

List:       kde-devel
Subject:    Re: The no goto religion
From:       "Robert Knight" <robertknight () gmail ! com>
Date:       2007-08-03 6:09:09
Message-ID: 13ed09c00708022309p6ddf8227h1255e6423a8030a3 () mail ! gmail ! com
[Download RAW message or body]

> If this takes a 25% performance hit, that
> makes a large difference in the icon lookup performance.

Real data is much more persuasive than speculation.  If you posted a
benchmark comparing your solution against the current code which
showed a definite performance improvement then I am sure the developer
community would pay more attention.

If you want to do something useful for KDE, by all means help us
optimise the applications, but I would appreciate you cutting down the
25 seconds it takes Kontact on a cold start on my laptop far more than
the microseconds I expect micro optimisations in your example could
save.

On 03/08/07, James Richard Tyrer <tyrerj@acm.org> wrote:
> Harry Bock wrote:
> > James Richard Tyrer wrote:
> >> Richard Moore wrote:
> >>
> >>> On 7/29/07, Kevin Krammer <kevin.krammer@gmx.at> wrote:
> >>>
> >>>> You could also just return the moment you found a match.
> >>>>
> >>> Yes, I've never in 10 years found a case where I'd want goto in C++.
> >>>
> >> The question here is not if it is possible to avoid a "goto" but rather
> >> how much extra code is used to avoid using one -- meaning that using the
> >> "goto" is sometimes the most efficient solution.
> >>
> > He never said he was explicitly avoiding them.  He said he has never
> > really found the need to use one.
> >> Read Frank Rubin's letter to Communications (of the ACM) for examples
> >> and Donald Knuth's paper: "Structured Programing with _goto_
> >> Statements". -- don't just take my word for it.
> >>
> >>
> > Trust us, we understand your stance on goto.  We know what it can save,
> > when it is helpful, when it isn't necessary, when it is too much, etc.
> > (even if some didn't, you've certainly made it clear) What you don't
> > understand is that we all have varying coding styles and preferences,
> > and most could really care less.  Just because you insist that goto is
> > the most efficient solution doesn't mean that everyone must follow your
> > advice and use it whenever you see fit, even though they understand it
> > very well (as this rather lengthy and fruitless thread has shown) and
> > even if their way is (very slightly) less efficient.
> >
> > If a programmer prefers multiple function exit points or repetitive
> > code, I wouldn't worry about it too much.  If you think it's evil to do
> > so, great, don't write it that way.  Use goto, use inline assembler
> > directives to insert whatever variation of the jump instruction is most
> > efficient, whatever.  But you can't convince everyone here that _they_
> > should do it whenever that situation arises, regardless of how many
> > cycles you gain or Donald Knuth articles you reference.
>
> It is nice to know that you understand what I am saying.  But, then you
> say things that indicate that you don't. Kunth's paper suggests, and he
> has hard numbers that using overly structured code can result in a
> serious performance hit.  Like my bicycle, not AJS's.
>
> This performance hit isn't that important in code that is only executed
> once in a while because although it slows that code down significantly,
> it doesn't make much difference in total performance.  However, with
> code, not what I used as an example but rather the similar code:
> "findMatchingIcon" which is the inner structure of the icon lookup code
> and it is executed a lot.  If this takes a 25% performance hit, that
> makes a large difference in the icon lookup performance.
>
> But, if you are saying that KDE coders don't care about efficient coding
> and the performance of the software, then I will simply have to accept
> what you say.
>
> --
> JRT
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
> <<
>
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]