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

List:       kde-devel
Subject:    Re: The no goto religion
From:       Matt Newell <newellm () blur ! com>
Date:       2007-08-03 14:29:01
Message-ID: 200708030729.01421.newellm () blur ! com
[Download RAW message or body]

On Friday 03 August 2007 02:37, James Richard Tyrer wrote:
> Robert Knight wrote:
> >> 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.
>
> I wouldn't say that a bench mark based on that specific instance would
> illustrate my point.  I just happened upon this example while fixing a
> bug.   My idea is simple -- that I have agreed with Knuth's paper ever
> since it was first published.
>
> You can get a poor (scanned) copy here for free:
>
> http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
>
> Although I had problems downloading it -- use "wget".
>
> You can get a OCR to text copy at acm.org if you are a member, or pay
> for it.
>
> What I am saying is that if he is correct and KDE consistently uses the
> "no-goto-allowed" style of coding that this will result in a significant
> performance hit.
You are wasting peoples time with crap statements like this.  You have no data 
to back up this assertion, and with my current understanding of the nature of 
most application code, I would say it makes no discernable difference.  There 
may be a handlefull of critical loops in KDE's code that could marginally 
benefit from a restructure using goto, but overall IT DOESN'T MATTER.  

If this issue is so important to you, then I challenge you to find a single 
code path in KDE that can be modified to use goto that will show a noticeable 
performance improvement to the user.

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