Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool2.mu.edu!uunet!microsoft!petergo
From: petergo@microsoft.UUCP (Peter GOLDE)
Newsgroups: comp.software-eng
Subject: Re: Effect of execution-speed on reliability/testing
Message-ID: <70101@microsoft.UUCP>
Date: 18 Jan 91 19:20:03 GMT
References: <1990Dec19.102005.11830@engin.umich.edu> <470@eiffel.UUCP> <1047@gistdev.gist.com> <15809.278a0d04@levels.sait.edu.au> <12212@pucc.Princeton.EDU> <6@microsoft.UUCP> <price.663815908@helios>
Reply-To: petergo@microsoft.UUCP (Peter GOLDE)
Organization: Microsoft Corp., Redmond WA
Lines: 39

In article <price.663815908@helios> price@helios.unl.edu (Chad Price) writes:
>Given that one has decided upon an algorithm which is 1) correct for the
>purpose, and 2) the most efficient that one can find; there are still
>many ways to code that algorithm.
>
>I agree that efficiency should not be considered until after coding is
>finished and a correct result is apparent (via testing ...). Then one
>should take the algorithm and analyze the method by which it is
>implemented and see if there are better ways to accomplish the same
>algorithm. 

I agree this can be a reasonable approach to some problems, especially
those with difficult or tricky algorithms, which is small and localized. 
I myself have used this approach, for example by first coding a routine 
in C and then recoding it in assembly code later.  

However, this wasn't really the point I was addressing in my 
original post.  I was responding to a claim that one should not
consider efficiency until one is done writing a _program_.  Since
a program is likely to take at least a year to complete, this involves
going back to code not considered for a very long time, possibly
written by someone else, and speeding it up, without breaking any
other code in the program at the same time.  Since most real speedups
are obtained by changing data structures, not by minor code tweaks, this
results in the all-too-common nightmare of trying to find all the
places that a given change impacts.  At best, you have to retest the
whole program; at worst, you can't make any changes at all because
you can't find all the places that depend on it.  Abstract data
types and object-oriented techniques can partially alleviate these
problems, but it is better not to have them at all.

This is the reason that I consider statements like "I won't worry
about efficiency now, I'll speed it up later" dangerous and 
unprofessional.  If speed (or space -- even harder to address after
the fact) is important then it is important enough to worry about
from the beginning.

--Peter Golde
petergo%microsoft@uunet.uu.net