Re^4: The Rules of Optimization Club

[petdance]

Nobody is saying don't optimize. In fact, I've never seen anyone say that "you should never optimize your code." If you can point me to someone who says that, I'd love to see it.

It's all about what "premature" is.

If your code is broken, then it's premature.

If you don't know the costs of your code, it's premature.

[JavaFan]

Nobody is saying don't optimize.

If you don't want to give that expression, I suggest you don't start posts with

The first rule of Optimization Club is, you do not Optimize.

Because you could have fooled me.

If your code is broken, then it's premature.

Eh, no. That's way to general. If a landslide just dumped a few metric tons of mud on my driveway, I'm not going to measure my progress while I'm digging with a spoon. I'll optimize that away right from the start. There's no point in continuing a work in progress of a fix if it's going to be too slow. Even if the fix leads to unbroken code. It's better to turn back and optimize *now* before spending the effort to reach an unsatifying situation.

While I agree that many optimizations are premature, I don't agree this is always true.

[petdance]

If you don't want to give that expression, I suggest you don't start posts with "The first rule of Optimization Club is, you do not Optimize."

Suggestion noted. I figure the intent is clear enough when rules 2-7 explain parameters for doing optimization.