Do many old ColdFusion Performance admonitions still apply in CFMX 8?

Question

I have an old standards document that has gone through several iterations and has its roots back in the ColdFusion 5 days. It contains a number of admonitions, primarily for performance, that I'm not so sure are still valid.

Do any of these still apply in ColdFusion MX 8? Do they really make that much difference in performance?

• Use compare() or compareNoCase() instead of is not when comparing strings
• Don't use evaluate() unless there is no other way to write your code
• Don't use iif()
• Always use struct.key or struct[key] instead of structFind(struct,key)
• Don't use incrementValue()

Answer 1

• Compare()/CompareNoCase(): comparing case-insensitively is more expensive in Java, too. I'd say this still holds true.
• Don't use evaluate(): Absolutely - unless there's no way around it. Most of the time, there is.
• Don't use Iif(): I can't say much about this one. I don't use it anyway because the whole DE() stuff that comes with it sucks so much.
• struct.key over StructFind(struct,key): I'd suspect that internally both use the same Java method to get a struct item. StructFind() is just one more function call on the stack. I've never used it, since I have no idea what benefit it would bring. I guess it's around for backwards compatibility only.
• IncrementValue(): I've never used that one. I mean, it's 16 characters and does not even increment the variable in-place. Which would have been the only excuse for it's existence.

Some of the concerns fall in the "premature optimization" corner, IMHO. Personal preference or coding style apart, I would only start to care about some of the subtleties in a heavy inner loop that bogs down the app.

For instance, if you do not need a case-insensitive string compare, it makes no sense using CompareNoCase(). But I'd say 99.9% of the time the actual performance difference is negligible. Sure you can write a loop that times 100000 iterations of different operations and you'd find they perform differently. But in real-world situations these academic differences rarely make any measurable impact.

Answer 2

I agree with Tomalak's thoughts on premature optimization. Compare is not as readable as "eq."

That being said there is a great article on the Adobe Developer Center about ColdFusion Performance: http://www.adobe.com/devnet/coldfusion/articles/coldfusion%5Fperformance.html

Answer 3

Coldfusion MX 8 is several times faster than MX 7 from all accounts. When it came out, I read many opinions that simply upgrading for the performance boost without changing a line of code was well worth it... It was worth it. With the gains in processing power, memory availability, generally, you can do a lot more with less optimized code.

Does this mean we should stop caring and write whatever? No. Chances are where we take the most shortcuts, we'll have to grow the system the most there.

Finding that find line between enough engineering and not over-engineering a solution is a fine balance. There's a quote there by Knuth I believe that says "Premature optimizations is the root of all evil"

For me, I try to base it on:

• how much it will be used,
• how expensive that will be across my expected user base,
• how critical/central it is to everything,
• how often I may be coming back to the code to extend it into other areas

The more that these types of ideas lie in the "probably or one way or another I will", I pay more attention to it. If it needs to be readable and a small performance hit results, it's the better way to go for sustainability of the code.

Otherwise, I let items fight for my attention while I solve and build things of real(er) value.

The single biggest favour we can do ourselves is use a framework with any project, no matter how small and do the small things right from the beginning.

That way there is no sense of dread in going back to work on a system that was originally meant to be a temporary hack but never got re-factored.