Hacker News Reader

Comment by noss | Hacker News Reader

«Leaving performance considerations aside, what possible difference does it make to the developer whether the CLR’s jitter happens to allocate memory for a particular local variable by adding some integer to the pointer that we call “the stack pointer” or adding the same integer to the pointer that we call “the top of the GC heap”?»

I'm all for avoiding premature optimizations, and giving priority to short and comprehensible code over faster code. But "leaving performance considerations aside" is like discussing dictatorship and "leaving human rights issues aside".

Good programmers have good hunches about performance, better programmers pick the shortest code anyway, the best programmers measure and then maybe optimize.

View on HN

The best programmers also know to think about performance when designing a system--if you completely abide by the strategy of "don't prematurely optimize", you end up with a system which wasn't designed with performance in mind, and often is very difficult to optimize later because of this. Sometimes the entire structure of the program has to be redesigned because the original method just was not suitable for performance.

A great programmer is able to think about performance at every point in designing something without obsessing about it to the point where it decreases reliability, readability, or extensibility.

I think you are correct, but your scenario is a good example of something else: Prototyping and "planning to throw one away" (Fred Brooks / The Mythical Man Month).

Having written one lousy implementation in X months does not mean that the good implementation, when starting over, will take X more months.

I have never seen a functional specification reaching more than 50% accuracy on details (most are not even close). When implementing you always discover more about the problem.

What stops you from starting over tends to be that the customers have integrated with your system according to published specs, or large roll-outs have been made already.

I think you are correct, but your scenario is a good example of something else: Prototyping and "planning to throw one away" (Fred Brooks / The Mythical Man Month).

Of course, but one is not always implementing a totally new system that justifies "throwing one away". Often one is implementing something whose design is well-known enough that one should expect to be able to do it right the first time.

Having written one lousy implementation in X months does not mean that the good implementation, when starting over, will take X more months.

Sure, but it still takes Y more totally unnecessary months, even if Y is less than X.

Isn't the time for measurement usually after the code has been mostly written? Not prematurely optimizing means getting to the measurement point as soon as you can, then using actual profiling numbers to focus your attention on what needs to be changed.

No, because then you may be locked into design choices that limit what you can optimize. If performance is important, experiment with the general idea of a design, and if its performance is acceptable, follow through.

If you wait until everything is mostly written, you risk finding out that a fundamental design decision is causing your performance problems.

I guess the tricky part here is defining the term "mostly written". My mistake for introducing it (and of course the tautological 'don't prematurely optimize').

Agreed, you should measure as soon as you can and it's best to be building and measuring, not guessing where your bottlenecks are up front.

Reply on news.ycombinator.com