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.
I was reading a great blog article earlier today about the use of StringBuilder, which provided very valid points, to which I provided some extra points about performance of the said class. However, I would hazard a guess that in many applications the optimizations discussed would make little difference, and even in the ones that did, only a small percentage of the uses would need such treatment.
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.
