When writing code I often spot some optimization opportunities, which I typically leave for later, just writing a small comment:
    // ToDo: Optimize this
I believe it is important to first get the behaviour right, and only consider detailed optmizations later.

Then one day the "optimization"-task becomes the top priority on my list, and then I am tempted to start by looking through all my recorded optimization opportunities to try and figure out which one will give me most performance for the least amount work. But then I think twice and instead look around for my favorite profiling tool. Because all the many times I have done this optimization exercise in the past the profiler have always found that the best optimization opportunity was one that I never even considered. So typically I end up never implementing any of the small optimization opportunities I have marked for myself. Maybe I should stop comforting my self by writing them, and just skip them...

I have used several commercial profiling tools in the past, and generally enjoy their ease of use: they can typically profile many different types of applications (web, libraries, command line) and they also typically have a "hot spot"-feature that immediately show you the way to interesting optimization opportunities. On Java I have been using OptimizeIt from Borland, and on the .NET platform I have used dotTrace from JetBrains.

However I recently discovered the open source profiler NProf. And while this tool does not have all the usability features of the commercial alternatives, the core profiling functionality is good enough for its inclusion in an open source tool chain.

NProf can only profile an executable, and I was using it for a web project. But fortunately I have a lot of tests, both unit tests and integration tests. And it didn't take long to write a small executable wrapper around one of my thorough integration tests and then firing up NProf on the resulting executable. And what did I see: that the most important optimization opportunity would be caching of configuration settings, cutting around 33% off the main call sequence of my application, something that had never occured to me...

To site Lord Kelvin: If you can't measure it, you can't improve it.

By Lars Thorup