Over Tweaking

There was a thread recently on the CFGURU mailing list about the merits of the various tweaks that CFML developers use to gain a few extra milliseconds. The consensus was that most performance problems won't be solved by using these tweaks, they typically lay within the database, application architecture, and lack of caching. Here are some tips:

• The tweaks often distract developer from the true bottle neck
• Often times these tweaks are discovered by timing loops, when load testing the differences are often negligible.
• Different versions of CF may alter the effectiveness of the tweak
• If you have found, and fixed all your bottlenecks, implemented caching, and have nothing better to do - then it may be a good time to start evaluating some of these coding tweaks. I say - have nothing better to do because the price of hardware is much cheaper than the cost of developing and testing.
• The JVM may end up optimizing for you - A technology called hotspot which exists inside the java virtual machine that will automatically perform byte code optimizations for you at run time based on the frequency of code execution. So when your doing a loop test you almost always going to invoke the hotspot compiler, and you are really just testing which code the hotspot can optimize better - but in the real world execution the function call may never end up in the hotspot.

This is all not to say that there are no best practices, there are - you need to evaluate the best practices to see if they make sense.

You should ask yourself before you do anything performance related if it improves your code quality; the readability, maintainability, and performance. If it does then it is a good practice.

Additionally the relative low cost of hardware issue is often an excuse for writing poor performing code. I'm not trying to advocate that you don't pay attention to performance, just that you should be focused when you tune your app. The 80/20 rule states that 80% of the execution time takes place in 20% of your code.