Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!osu-cis!dsacg1!ntm1063
From: ntm1063@dsacg1.UUCP (James Haskins)
Newsgroups: comp.org.usenix
Subject: Re: potential paper topic
Message-ID: <648@dsacg1.UUCP>
Date: 16 Feb 89 13:06:44 GMT
References: <1989Feb15.194802.15252@utzoo.uucp>
Organization: Defense Logistics Agency Systems Automation Center, Columbus
Lines: 26


 From article <1989Feb15.194802.15252@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):

Stuff deleted....> mind.  The authors by and large followed the (sensible) philosophy of
>
 "first make it work, then make it fast"... except that in practice this
> usually turned into "first make it work, then lose interest and go do
> something else".
> -- 
> The Earth is our mother;       |     Henry Spencer at U of Toronto Zoology
> our nine months are up.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
One of the points that Software Performance Engineering tries to make is that
performance must be designed in from the beginning.  Adding it later usually
doesn't work, for reasons such as you stated.  I haven't attended USENIX
(that is reserved for my best UNIX guy), but I do attend the Computer
Measurement Group (CMG) International Conferences and there has been an
ongoing thread of papers, panel discussions, and BOFs on the problems of
performance engineering.  Something along the lines you have suggested would
be interesting, particularly in regard to the problems encountered when trying
to tune after the fact.  If anyone is interested, some discussion along the
lines of these problems (in the comp.software-eng group?) would be nice.
-- 
Jim Haskins
DLA Systems Automation Center                     | 614 238-9432
DSAC-TMP P.O. Box 1605 Columbus, Ohio 43216       | Autovon 850-
All opinions expressed are mine alone etc., etc.