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.

Other pages within this category

comments powered by Disqus

This site uses cookies to analyse traffic, and to record consent. We also embed Twitter, Youtube and Disqus content on some pages, these companies have their own privacy policies.

Our privacy policy applies to all pages on our site

Should you need further guidance on how to proceed: External link for information about cookie management.

Send a message
X

Please use the forum for help with UI & libraries.

This message will be securely transmitted to our servers.