Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pdn!nike!locke
From: locke@nike.paradyne.com (Richard Locke)
Newsgroups: comp.software-eng
Subject: Re: Effect of execution-speed on reliability/testing
Message-ID: <1991Jan4.175558.19254@pdn.paradyne.com>
Date: 4 Jan 91 17:55:58 GMT
References: <1990Dec19.102005.11830@engin.umich.edu> <470@eiffel.UUCP>
Sender: news@pdn.paradyne.com (News Subsystem)
Reply-To: locke@nike.paradyne.com (Richard Locke)
Organization: AT&T Paradyne, Largo, Florida
Lines: 66
Nntp-Posting-Host: nike

In article <470@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>From <1990Dec19.102005.11830@engin.umich.edu>
>by zarnuk@caen.engin.umich.edu (Paul Steven Mccarthy):

>> ...The impression that I 
          ^^^^^^^^^^
>> have gotten from most professionals in the software trade is something
>> like: "Speed isn't important.  The hardware will speed up and take care
>> of our inefficiencies."
>
>This is quite interesting. I don't remember ever reading any such
>comment....
>Coming back to the published literature, here is a a question
>to Mr. McCarthy: can you quote a publication in the field
>which states that ``speed is not important''?

I think Mr. Mccarthy [sic] was just exagerating a bit for the sake
of discussion.  One might restate things as "Good design and coding
practices are more important than execution speed, in part because
hardware will speed up..."

One could get Mccarthy's impression even by a superficial glance at Meyer's
book, where the quality factors of correctness, robustness, extendibility,
reusability, and compatibility are showcased.  Execution speed is
group with "other qualities" -- though "good use of...resources...
is of course an essential requirement...." ;-)  Anyway, that's really
the point -- competent professionals will always strive to make
good use of resources.

In some applications execution speed is clearly crital and needs to
be considered as an integral part of the requirements; not so in
others.  If you want to read the comments of a real speed freak,
check out Bill Gates in "Programmers at Work".  When he started out
programming on slow machines, he clearly was correct in placing
strong emphasis on speed.  Such an obsession is obviously uncalled for
in a minor and infrequently used feature of a system running on a fast
processor.  It all depends on what you're trying to accomplish.

Boris Beizer (author of "Software Testing Techniques") has some
inflammatory things to say about performance.  In his test class
notes, he says:

	good algorithms far more important than code details
	programmer's perspective on performance usually wrong
	do it straight and simple and redo it if it turns out
		to be a problem
	justify all horrors in the name of performance by a formal
		quantitative, statistically valid, in-context, model
	no module accounts for more than 5% of execution time yet
		every programmer "optimizes" his code (anecdote)
	programmers confuse the need for path with the execution
		probability of the path and so all paths are
		"optimized"
	execution time is still being preached and trained even
		though it is important only in exeptional cases
	detailed modeling and measurement of software shows that
		programmers haven't the slightest knowledge of
		the performance impact (or lack thereof) of their
		program

Boris says the three best ways to destroy quality are to
squeeze the schedule, squeeze the code (memory), and squeeze
execution time.


-dick