The Fallacy of Premature Optimization (sometimes it's good)

acm.org

14 points·smanek··4 comments

I conjecture that the more low-level the language, the more premature optimization is necessary.

As an example, an assembly language programmer has to make very early decisions about whether to use a WORD (valuing speed), or a long (valuing extensibility) to model a quantity. If he chooses wrong, he will have to modify hundreds of lines of code. A C programmer, instead, can use a typedef and then switch between the two representations at any time, but he might have to choose between long and big-integer. Lisp programmers don't have that choice to make.

In the perfect HLL (by that metric), every parameter or constraint of the program is specified in just one place. Premature optimization is then always a mistake.

(Lisp still has a way to go to get there)

Seemed wordy and off-base. Are there really people out there who think all optimization is evil?

Seems like a very longwinded attack on a "optimization is evil"-strawman. However, he has one valid point: You should consider performance issues when you design the overall architecture of a system, even though this is prematurely in the sense that it is too early to actually measure where the problems might be.

There are. I've had the misfortune of working with people like that frequently. It leads to a lot of frustration, because they tend to write very verbose and convoluted code with very little documentation, so in addition to performing poorly, it's a pain to read and debug.

Naturally, they aren't up to the task of debugging their own code, let alone optimizing it...

Reply on news.ycombinator.com