Only try optimization when you have knowledge of the actual bottleneck

I have seen architects who spend great effort on:

• Fine-tuning logging statements
• Replacing Vectors in legacy code
• Replacing + operators with StringBuffers in loops
• Refactoring existing, stable, mature and bug-free code for the sake of “performance”
• …and other fancy stuff

Sadly, this is done without actually measuring what effect these efforts might have. Even if the application runs a bit faster, most of the times there are other more serious problems (like database locking, memory leaks, streams that are never closed/flushed) that nobody pays attention to.

Spending time to fix logging and gain 3% in speed is not very helpful when fixing the SQL queries would give 200% gains in speed.

Therefore, it’s important to keep in mind that any change that happens for performance reasons is actually a four-step process:

1. Measure the current system (valid benchmarks are a big task on their own)
2. Apply the change
3. Measure again
4. Evaluate the effort given and the performance gained ratio.

Remember the mantra for optimizations – measure, don’t guess.