Re: [9fans] plan or side effect

[Dan Cross <cross@math.psu.edu>]

No Tom, the point is that it's easier to verify that something is
correct if it's simpler.  Performance is, to a lot of folks (myself
included) less important than correctness.

These are all pretty straight forward engineering tradeoffs; how much
time am I willing to invest in making something go faster?  Is it worth
while for me to do so?  What is the cost of maintaining that thing?  If
you're a resource constrained group like 1127, and performance isn't
such a big deal to you, you're not going to worry about making a
super-fast whiz bang optimizer, or about hand coding the universe's
most efficient implementation of strcpy.  It's just not important.

Another good engineering principle is ``optimize for the most common
case.'' Imagine that you build a system, and you find that you spend
90% of your time in one, rather small, part of that system.  If the
performance of the system is still acceptable, you probably aren't
going to worry about it.  But, if you do need to make it faster, where
do you get the biggest return on your investment in optimizing: in that
one part, or on the system overall?  Usually, it's in that one part.

The Plan 9 guys at the labs took these things to heart when they built
the compiler suite.  They saw themselves spending a lot of time
compiling, and not worrying too much about performance of the compiled
code.  The end result is what we see in 8[acl] et al; you get very
speedy compilation, and medium quality output with acceptable
performance.  You don't have the maintenance overhead of something
really big like gcc.  Overall, the system is very well balanced in
terms of compiler output quality, compiler speed, and maintenance costs
associated with the compiler suite.  The compiler is well suited to the
unique Plan 9 environment.  Really, I don't see what your problem with
the Plan 9 compilers are, Tom.

	- Dan C.