guthery@acw.UUCP (Scott Guthery) (10/24/89)
Functionality first and performance at the end is wrong. If you
care about performance then you should design it in not hack
it in. Furthermore, you might avoid the situation where the
design you've implemented simply can't be whipped up to speed.
If all you want is as fast as possible, then by all means
profile and stomp on the hot spots. But if you have a performance
bogey, then you'd better care quantitatively from the start.
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?
Cheers, Scott
+*+*+*+*+*+*+*+*+*+*+*+*+ Austin Code Works +*+*+*+*+*+*+*+*+*+*+*+*+*+*+**+*+
NET Domain: guthery@uunet.uu.net Post: 11100 Leafwood Lane
COM Domain: guthery@acw.com Austin, Texas 78750-3409 USA
US Domain: guthery@acw.austin.tx.us FAX: +1 (512) 258-1342
Usenet: {uunet}!acw!guthery Voice: +1 (512) 258-0785
CompuServe: 70240,221 TELEX: 446370 (austincodewrks)
Packet: N5MDE @ KB5PM EasyLink: 62752994
Fidonet: 1:382/12 Prodigy: KSWS89A
+*+*+*+*+*+*+*+*+*+*+*+*+* The Source of C +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+davidm@uunet.UU.NET (David S. Masterson) (10/26/89)
In article <27.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes:
Functionality first and performance at the end is wrong. If you
care about performance then you should design it in not hack
it in. Furthermore, you might avoid the situation where the
design you've implemented simply can't be whipped up to speed.
If all you want is as fast as possible, then by all means
profile and stomp on the hot spots. But if you have a performance
bogey, then you'd better care quantitatively from the start.
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?
This type of performance stricture should only be applied in the development
of a particular system, not in the development of an application. The
difference between application and system is that typically an application is
seeking to solve a problem whereas a system is an mechanism to be used in
implementing a solution to a problem, but in and of itself is not the solution.
In the development of an application, the hard part is usually finding the
solution to the problem, performance can be cleaned up later (it is never
completely out of consideration, but certain stages of development have other
priorities).
In the case of application development, the thrust should be on the
development of a model for the application that shows a complete, clear, and
concise method of solution for the problem. Design of this model (*by
definition*) should take into account the requirements of functionality and
performance. My contention is that once development of this model is complete
and there is an implementation of the application, performance and
functionality for the application will be adequate, if not necessarily
acceptable. At that point, system development can begin to find a better
mechanism for implementing the application model.
--
===================================================================
David Masterson Consilium, Inc.
uunet!cimshop!davidm Mt. View, CA 94043
===================================================================
"Nobody here but us chickens..."marc@dumbcat.UUCP (Marco S Hyman) (10/26/89)
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