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.
Comments
So true. A few years back, I was asked to help a developer who was actually crashing Sybase. The developer was looping over a recordset with 1000+ records. With each iteration of the loop, she was making another 5 queries against the database to "join" the related tables. A single request to the CF page would make 5000+ calls to the database. I re-wrote the code for her, making all of her joins in one query. After it worked, her answer was "That can't be right, I'll have to come in this weekend and work on it." The largest contributor to bottlenecks, that I've seen, is improper database interaction (also including design). Many developers can save themselves trouble if they would pick up Ben Forta's Sams Teach Yourself SQL in 10 Minutes. For the developer who finds himself/herself in the database design boat, Groff Weinberg's SQL - The Complete Reference is a nice primer. Of course, there are also other cosiderations, including hardware, webserver, and database server configurations too.