By dave | June 30, 2012

As a developer I often feel the need to performance tune code, or write “the best piece of code ever”. Sometimes this happens even before I know which sections of the code will be executed frequently? These days I make every attempt to hold back from this approach.

In applications where performance is critical I usually write it the most natural way and apply any optimisations required later. Usually in such systems I am more worried about garbage collection / not getting a cache hit for memory, than outright CPU performance. Generally speaking these days CPU time is cheap - not that I am condoning lax programming techniques.

Disk is many times slower than memory, and memory is many times slower than the cache which feeds the CPU. If you incur a memory barrier (from synchronization etc) or cache miss, that costs time while the memory is accessed. This I believe is one of todays hard to solve performance problems, but again only when in critical code sections.

For example on a few blogs, the idea that StringBuilder, will always outperform simple string addition is still presented. This is not always the case anyway unless the capacity is set upfront, as the compiler may well make the same choice.

For example:

StringBuilder s = new StringBuilder();

Will generate a builder with a capacity of 16 on everything at least up to Java 7. By default when string addition is used, it picks that default size as far as I can tell. If you go to the effort of using StringBuilde, make sure you set a large enough capacity. Let’s be honest, in how many cases would the above change actually matter. Again, probably only in the critical code segments.

To back up this view, the hotspot JVM is based on the same pattern, only a small percentage of the code needs to be optimal, and each piece of code must show its worth to the JVM by being executed many times, before being compiled.

So my beliefs in short are to avoid over optimisation, checking the application in question actually needs to be optimised, and more importantly knowing what constitutes acceptable performance for the application in question before starting. Without knowing the acceptable limits, its hard to break out of the optimisation cycle.

comments powered by Disqus
We use cookies to analyse traffic and to personalise content and adverts. Our social buttons may also use cookies.