Thursday, June 28, 2007

On Optimization and Tuning

I came across reading the basic principles of optimization and performance tuning from two books, and I actually thought of sharing it here:

Chapter 1 of Java Performance Tuning:

Don't Tune What You Don't Need to Tune

The most efficient tuning you can do is not to alter what works well. As they say, "If it ain't broke, don't fix it." This may seem obvious, but the temptation to tweak something just because you have thought of an improvement has a tendency to override this obvious statement.

Item 37 of Effective Java Programming:

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason—including blind stupidity.

– William A. Wulf

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

– Donald E. Knuth

We follow two rules in the matter of optimization:

Rule 1. Don't do it.
Rule 2 (for experts only). Don't do it yet—that is, not until you have a perfectly clear and unoptimized solution.

– M. A. Jackson

As mentioned in the book above, performance issues should be thought of while the application is being designed. Therefore,

  • A good design is very important. Spend more time on the design or spend even more time to get things really working happily one day
  • Don't do optimization if:
    • You have not gotten something working yet
    • The measurable gain is insignificant

- yc, reading


Unknown said...

I don't place too much focus on optimization or performance during coding. However, I do keep a level of awareness that my code should not eat up all the system resources at incredibly high speeds.

I believe most performance evaluation should be done before coding and after it. Think of it as an around interceptor in AOP terms.

Say you want to write another Confluence. You can write the search engine using a massive clump of clumsy SQL statements. However, there are many concerns over the SQL approach. One of them would be scalability.... and that is a very performance oriented concern, don't you think? So, you need something that is _fast_. You'd search for alternative approaches to write a search engine with a heavy emphasis on performance and scalability. Yeap. Lucene.

However, I wouldn't really worry about how I can make Lucene queries perform faster in my code as I'm writing it. I'll probably do that after the development is done and there are problems with it in that context.

To me, no rules are always true. I do make mini performance considerations as I'm writing code. For example:

# Implementation of java.util.List to use
# Implementation of java.util.Map to use
# Synchronize or not

Christian Ullenboom said...

I'm not a big fan of Jack Shirazi's book because it is very low level (switch better if?, shift better than mul/div?, ...). But I like his website! It is awesome: