Comments on: a case for premature optimization

By: computinglife

computinglife — Thu, 25 Oct 2007 14:31:08 +0000

Shahar,

My experience has been that

Defining the load & performance estimates is one thing
Obtaining the said performance is usually another.

There is no way the performance levels one require can be obtained without actually planning & designing around it. (which is what you pointed out too). The fact that folks do not consider this in their designs is my peeve.

By: Shahar Evron

Shahar Evron — Thu, 25 Oct 2007 14:20:49 +0000

The keyword in “premature optimization” is “premature” – and the way I understand “premature” in this case is either “ahead of it’s time” or “in the wrong place”. This does mean that optimizing before you release is wrong – it means that spending time on optimizing pieces of code which might or might not be causing bottlenecks before you know where your bottlenecks are, is wrong.

If you’re building a piece of software that, as part of it’s initial requirements, is designed to handle heavy load – what you need to do is first of all *define exactly* the amount of load you need your software to handle as parts of your requirements. Then, build your software in a way that will be best performing – but don’t spend too much time optimizing the performance of parts without actually having some intelligent clue of how cost effective what your doing is. Instead, spend your time designing your software in a way that it can be easily optimized (a simple example: so that you’ll be able to move from one RDMMS to another easily) when you do have a clue about where the bottlenecks are.

Oh, and also if your goals define the stress you’re supposed to handle, stress testing should be an early part of your testing phase – this way you can decide whether your code handles the load it’s supposed to, and if not, find your bottlenecks (a good profiler is all you need in some cases) and then – optimize (when that time is right that is!)

By: computinglife

computinglife — Wed, 10 Oct 2007 11:59:37 +0000

Would you shell out 10,000$ for a car that goes only at 10 miles per hour?
(A cycle – 150$ can go faster than that)

By: Ammu

Ammu — Wed, 10 Oct 2007 11:53:43 +0000

No one has ever written anywhere that a car will b functionally complete ONLY if it goes faster than 10 miles per sec. How can u say a software is functionally complete ONLY if it works fast? If it does what it’s supposed to do it is functionally complete isn’t it? Working fast is an extra requirement rt? It wud b good if the car goes a little more faster. Similarly it wud b better if the software performs the task a bit more faster.

By: computinglife

computinglife — Thu, 12 Jul 2007 10:27:43 +0000

In fact i was advocating premature optimization

By: Eswar

Eswar — Thu, 12 Jul 2007 10:21:48 +0000

Ok, you say premature optimization is evil. What i say from database point is that, optimization starts from day 1. May be its the other way in software, but when you start design the database, start design the schema, there you start performance optimizations. Planning is the key word i would like to use. If plan has leaks, so do software, no matter what it does!