Web Biz

    I came across a document that outlines suggested techniques that CF programmers should adhere to in order to improve the performance of their code.  Here is a summary of these techniques:

Performance "Do’s"

Use compareNoCase() for comparing two values

Use compareNoCase() or compare() instead of the is not operator to compare two items. They are significantly faster. Remember that these functions return 0 if the values match, so they correspond to is not.

Example: <cfif compareNoCase(x, "a")>
Not: <cfif x is not "a">

Use listFindNoCase() for OR comparisons

Use listFindNoCase() or listFind() instead of the is and or operators to compare one item to multiple items. They are much much faster (order of magnitude for 5+ options).

Example: <cfif listFindNoCase("a,b,c", x)
Not: <cfif x is "a" or x is "b" or x is "c">

Use arrays instead of lists - in general

In CFMX, lists suffer from the generally slow string processing in Java which means that list manipulation can be slower than in CF5. In general, it is better to work with arrays of items instead of lists of items: listGetAt() is not an efficient way to work with individual items in a data set! However, see the list vs array caveat in the Don’t section below.

Use cfqueryparam to increase query performance

You can use cfqueryparam to optimize a query that looks something like this:

^?View Code COLDFUSION

1 2 3 4 5 6

SELECT * FROM TABLE_NAME WHERE COLUMN = #variable#

If this query is executed repeatedly with different values for variable then using a SQL ‘bind’ variable will be faster. cfqueryparam creates these ‘bind’ variables:

^?View Code COLDFUSION

1 2 3 4 5 6

SELECT * FROM TABLE_NAME WHERE COLUMN = <cfqueryparam cfslqtype="cf_sql_xxx" value="#variable#">

This allows the optimizer to compile the query once and reuse it every time the query is executed. It is also more secure since it prevents rogue SQL from being passed into a query (because it validates the type of the data).

Use blockFactor to increase query performance

Adding blockFactor to a query can significantly improve performance. To add blockFactor, examine the data that is being returned. Determine the maximum size (in bytes) of each row. Take that size and determine how many times that number would divide into 32k. That number is your blockFactor, but be aware that the max blockFactor is 100. So, if for example you were getting 200 bytes per row, you could easily fit over 100 rows into the 32k buffer that CF ‘grabs’ at one time.

If you know at runtime that you will have less then 100 rows returned, for example you’re writing a query that either returns 0 or 1 rows, do not bother adding the blockFactor attribute.

Performance "Don’ts"

Don’t use evaluate()

Avoid evaluate() unless there is no other way to write your code!

Don’t use iif()

Always use cfif/cfelse instead of iif(). It is significantly faster and more readable.

Don’t use structFind()

Always use struct.key or struct[key] instead of structFind(struct, key). They are significantly faster and more readable.

Don’t slavishly convert lists to arrays

Even though manipulating an array is generally faster than manipulating a list in CFMX, if you simply need to iterate over a list of items and process each one in turn the faster construct is <cfloop list="#itemList#" index="x"> … </cfloop>. Don’t convert itemList to an array and then loop over that - it’s not worth it because it probably won’t be faster.

Don’t use cfmodule

It’s slower than a CFC method invocation, it’s slower and uglier than using a custom tag with a prefix, it’s even slightly slower than a regular custom tag invocation. Better options exist: use a CFC (preferred), use cfimport and invoke a custom tag (always preferable to invoking a custom tag via cfmodule) or even simply including a file.

Don’t use incrementValue()

Always use x = x + 1 instead of x = incrementValue(x). It is more readable and slightly faster.  Note: In situations where x + 1 is not legal, incrementValue(x) will be more readable than creating a temporary variable to hold x + 1 and then using the temporary variable.

Don’t use WDDX for hardcoded data

It is always faster to cfinclude a CFML file that defines a datastructure than it is to deserialize a WDDX packet of that datastructure somewhat faster if the packet is in memory, and significantly faster if the WDDX packet is read with cffile. Use this technique if the datastructure can be hardcoded (i.e., don’t ship .wddx files, ship .cfm files). The Site-wide Variables technique is a good example of this.  Note: Complex or frequently changing configuration data is best implemented using an appropriately designed XML file.