Wednesday, February 27, 2008

Premature Optimization and the evil

Right from the day I have started designing applications, I have been hearing people quoting the famous words,specifically dealing with "performance".
Premature optimization is root of all evil - Sir Tony Hoare (popularized by Donald Knuth)

As we aware, the words like "Premature", "Optimization" and "evil" these are generic terms and open for interpretations with no SMART objective associated with them. Developer to PM to architects, each interprets the above quote in their own way and, sometimes using it to their own advantage as and when needed.

let me share my perspective of the above quote. "Premature optimization" has two important hidden pointers. First one, the "time/period" i.e. how much "premature" is acceptable. The second pointer is "quantity" i.e. how much "optimization" is necessary.

Let me start with the second pointer "Optimization". Optimization of any application could be done at various stages. During the design stage, implementation and pre release. So, what stage is ideal to do performance optimization ? Or, should it be done continuously ?

My experience shows that following steps are needed during performance optimization
  • performance criteria needs to be well understood at the beginning of the project,
  • it should be explained to all team members(means testers included)
  • Good design and coding guidelines(ex: proper use of String Vs StringBuffer, use of sets, hashmaps, etc) around performance needs to be created and taught to the development team
  • Each component/module needs to be designed to satisfy the ground rule created at the beginning around performance, and excess tuning needs to be avoided.
  • Check points at regular intervals should be created and performance testing should be done
Summary of my understanding around premature optimization quote is,
  • Optimizing design,code is a continuous process happening throughout the development cycle.
  • excess application optimization at the beginning of the project should be avoided
My thoughts mentioned above are also reflected pretty much in this artice, and the author has gone in depth and has given a good explanation around premature optimization.



1 comment:

Anonymous said...

Apache is 15 years old. And optimizations are just not there. As a result, it is at the bottom of all benchmarks -and uses (much) more hardware than necessary (see TrustLeap for a clue).

So, when to optimize? Upfront? After? Or is it just a question of style?

We all become what we do. Do junk and you will only be a good junk producer. Do marvels and you will become better and better at it.

It takes quite a while to learn how to do well. But it pays also.

If you have enough grey matter, that's a no-brainer: do it as well as possible.