Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!usc!ucsd!ucbvax!mtxinu!unisoft!hoptoad!hsfmsh!dumbcat!marc
From: marc@dumbcat.UUCP (Marco S Hyman)
Newsgroups: comp.object
Subject: Re: Performance & Functionality
Summary: Change the algorithms
Message-ID: <115@dumbcat.UUCP>
Date: 26 Oct 89 03:36:32 GMT
References: <27.UUL1.3#913@acw.UUCP>
Reply-To: marc@dumbcat.UUCP (Marco S Hyman)
Organization: MH Software, Hayward, Ca.
Lines: 22

In article <27.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes:
    Consider the situation where all the hot spots are gone, the
    profile is flat, and it's still not fast enough.  How now, 
    brown cow?

Then you change the algorithms.  This is one of the big wins in
object-oriented software.  Assume a reasonable design (yes, the desired
response time or thruput or whatever must be a design goal).  Now assume
that the good design properly delineates objects -- that the interfaces are
correct for the desired data flow.  Therefore, any of the algorithms used to
implement the objects can be changed and the ONLY effect on the system will
be better (or worse) response time, thruput, etc.

We might be saying the same thing -- the desired efficiency MUST be one of
the design goals.  But I often code a quick and dirty n**2 algorithm just to
get things going, knowing that once everything is working I can always go
back and replace it with an n log n algorithm later.  (I call the first
implementation a prototype to make myself feel better :-)

--marc
-- 
// Marco S. Hyman		{ames,pyramid,sun}!pacbell!dumbcat!marc