Message from discussion The psychology of premature optimization
From: raff...@mediaone.net (Raffael Cavallaro)
Subject: The psychology of premature optimization
References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
X-Trace: brnws01.ne.mediaone.net 913783860 184.108.40.206 (Tue, 15 Dec 1998 23:51:00 EDT)
Organization: Northeast Region--MediaOne
NNTP-Posting-Date: Tue, 15 Dec 1998 23:51:00 EDT
In article <751efs$oj...@sparky.wolfe.net>, "Chas Wade"
<chasw...@wolfenet.com> wisely wrote:
> My experience has been that programmers are too eager to get faster
>performance, and they both constrain their designs, and program too
>carefully for performance in the early stages of a project. Build first, th
>en work on the performance. If your tools let you build fast enough, you
>won't be disheartened by discarding even large portions when they prove too
>slow because you can rebuild a second solution just as quickly.
Here's my take on why people optimize prematurely, FWIW. Life is
uncertain. Will your project succeed? Will you be working at the same
company in 6 month's time? Will you reach the market in time? etc., etc.,
etc. The honest answer to all of these is "I don't know."
But one thing is for sure. If I work at it, I can get this bit of code to
run faster. It's manageable, it has immediate, visible results, even if
these results are irrelevant to the bigger questions we're really
So people try to manage their uncertainty by being certain about somthing
they can deal with directly - the speed of their code.
It really makes much more sense to let the compiler writers worry about
the speed of generated code - after all, that's what they do for a living.
Only once we've gotten something to work should we turn to the task of
speeding up selected, critical portions that the compiler didn't make fast
enough for our purposes.
just my $.02 worth.