String methods: ColdFusion vs. Java
You may know from previous blog posts that I strongly advise every ColdFusion developer to familiarize himself/herself with the thing that actually makes ColdFusion tick, i.e. with Java. Everybody who writes a single line of CFML should know about the possibilities of extending ColdFusion by directly accessing the underlying Java methods of certain objects. One of the datatypes where actually using Java may make a lot of sense is the string object.
ColdFusion string literals are just plain old Java strings. If you grab a string from e.g. a query object like variables.qMyQuery.myTextColumn, you need to be careful though - even if you think you just have one tuple returned, you've got something other than a string object on your hands. In such a case you need to either specifically target a certain row (like variables.qMyQuery.myTextColumn[1]) or you wrap it up in a JavaCast like Javacast('string',variables.qMyQuery.myTextColumn).
I finally found a moment to actually do some benchmarking on some of the built-in ColdFusion functions against their Java counterparts. This is not a benchmark of Java vs. ColdFusion performance, mind you, it's about deciding whether to use Java-methods inside of ColdFusion vs. ColdFusion's built-in string functions.
Using client-side caching in ColdFusion
The cheapest request you can think of is the one where you actually don't need to provide an answer - because you have answered it before and you know that facts haven't changed. Now server-side caching is one approach, but in that case you just save yourselves the actual computing, you still have to retrieve your answer from the cache and deliver it to the client. Client-side caching is much more elegant.