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

List:       kde-devel
Subject:    Re: The no goto religion
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2007-08-05 3:21:00
Message-ID: 46B5421C.6000703 () acm ! org
[Download RAW message or body]

Robert Knight wrote:
>> His numbers are based on how
>> the code would compile.  Not on actual execution in a specific
>> architecture.  I don't think that there is any doubt that, in most
>> cases, more instructions will result in longer execution time.
> 
> I have now read the PDF of the paper you linked to.  It was an
> interesting read, thank you for providing the link.
> 
> However, I believe that it does not support the theme of your posts.
>>From the introductory section in which Knuth provides the background
> to the debate (page 268):
> 
>   "A good programmer
>   will not be lulled into complacency by such
>   reasoning, he will be wise to look carefully
>   at the critical code; but only after that code
>   has been identified. It is often a mistake to
>   make a priori judgments about what part
>   of a program are really critical, since the
>   universal experience of programmers who
>   have been using measurement tools has been
>   that their intuitive guesses fail."

Yes, he is correct there.  Not exactly the issue that I intended to 
discuss though.

> And just before that, the now legendary quote:
> 
>> We should forget about small
>> efficiencies, say about 97% of the time: pre-
>> mature optimization is the root of all evil

I don't think that that should be interpreted to mean that writing poor 
code is acceptable.

The paper covers various issues some of which are off topic.  However, 
IIRC, it does make a good case for the use of "goto" in structured 
programing.

I intended to raise only one specific issue:

Adding extra code to avoid the use of a "goto" statement is poor 
programing practice and in most cases will increase the run time.  This 
can often be avoided by using peephole optimization -- checking to see 
if the same thing is being done twice within a few lines.

The Frank Rubin letter addresses only the issue I have raised.

I am not suggesting applying micro optimizations which make the code 
harder to read such as some of those in the paper.

-- 
JRT

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