|
Unix Programming - Basics of the Unix Philosophy - Rule of Optimization:
Rule of Optimization:
Prototype before polishing. Get it working before you optimize
it.
The most basic argument for prototyping first is Kernighan &
Plauger's; “90% of the functionality delivered now
is better than 100% of it delivered never”. Prototyping first
may help keep you from investing far too much time for marginal
gains.
For slightly different reasons, Donald
Knuth
(author of The Art Of Computer Programming, one
of the field's few true classics) popularized the observation that
“Premature optimization is the root of all
evil”.[11]
And he was right.
Rushing to optimize before the bottlenecks are known may be the
only error to have ruined more designs than feature creep. From
tortured code to incomprehensible data layouts, the results of
obsessing about speed or memory or disk usage at the expense of
transparency and simplicity are everywhere. They spawn innumerable
bugs and cost millions of man-hours — often, just to get marginal
gains in the use of some resource much less expensive than
debugging time.
Disturbingly often, premature local optimization actually
hinders global optimization (and hence reduces overall performance).
A prematurely optimized portion of adesign frequently interferes with
changes that would have much higher payoffs across the whole design,
so you end up with both inferior performance and excessively complex
code.
In the Unix world there is a long-established and very explicit
tradition (exemplified by Rob Pike's comments above and Ken
Thompson's
maxim about brute force) that says:
Prototype, then
polish. Get it working before you optimize it
. Or: Make it
work first, then make it work fast. ‘Extreme programming' guru
Kent Beck,
operating in a different culture, has usefully amplified this to:
“Make it run, then make it right, then make it
fast”.
The thrust of all these quotes is the same: get your design
right with an un-optimized, slow, memory-intensive implementation
before you try to tune. Then, tune systematically, looking for the
places where you can buy big performance wins with the smallest
possible increases in local complexity.
|
Prototyping is important for system design as well as
optimization — it is much easier to judge whether a prototype
does what you want than it is to read a long specification. I
remember one development manager at Bellcore who fought against the
“requirements” culture years before anybody talked about
“rapid prototyping” or “agile development”. He
wouldn't issue long specifications; he'd lash together some combination of
shell scripts and awk code that did roughly what was needed, tell the
customers to send him some clerks for a few days, and then have the
customers come in and look at their clerks using the prototype and
tell him whether or not they liked it. If they did, he would say
“you can have it industrial strength so-many-months from now at
such-and-such cost”. His estimates tended to be accurate, but
he lost out in the culture to managers who believed that requirements
writers should be in control of everything.
|
|
| --
Mike Lesk
|
|
Using prototyping to learn which features you don't have to
implement helps optimization for performance; you don't have to
optimize what you don't write. The most powerful optimization tool in
existence may be the delete key.
|
One of my most productive days was throwing away 1000 lines of
code.
|
|
| --
Ken Thompson
|
|
(We'll go into a bit more depth about related ideas in Chapter12.)
[an error occurred while processing this directive]
|
