It was an article by Michael Dinowitz, "Comparisons with CFIF," that made me reevaluate how I was writing my CFIF statements.

Since the common <CFIF myVar IS Value> was the slowest way to compare two strings, the table of data presented in the article (see Fusion Authority, 1/10/00, www.houseoffusion.com) seemed incomplete to me. I wondered what the performance data would show for integers - and for Boolean tests, as we all write tons of those in our code as well.

Other common CFIF tasks were also missing, such as tests for existence and bitwise operator tests. I wanted to know the best way to optimize all of these CFIF operations instead of just string comparisons. I also wanted to update the data with ColdFusion 5 to see if it was still valid or if CF5 had changed the results in any way.

I found that the String "COMPARE" function is still the best choice for string comparisons. For Boolean and integer uses "myVar IS value" had the best results.

Tests for existence showed that IsDefined() performance is almost identical to the older ParameterExists, so we know we aren't giving up anything by using the newer function. The bitwise operator tests surprised me. It's well known that bit operations are faster than multiplys. The CFML implementation of BitAnd was slower than using MOD to test for even or odd numbers. Bit Shift Left was slower than doing a simple multiply, which was also surprising. The good thing is, you don't have to learn bitwise operators to get maximum CFML performance. If CFML had true bitwise operators instead of bitwise functions, we'd likely get that improved performance since we'd be eliminating the overhead of the function calls.

All tests were made with the following basic code; "TESTING CRITERIA" was where I entered in the operation I was testing.

<cfset tickBegin = GetTickCount()>
<cfloop index="i" from="1" to="#iterationcount#">
<cfscript>
myvar = i;
if ( TESTING CRITERIA )
myvar = i + 3;
</cfscript>
</cfloop>
<cfset tickEnd = GetTickCount()>
<cfset loopTime = tickEnd - tickBegin>

For each series of measurements I tested three conditions to measure if there was any difference in handling smaller loops versus larger loops:

• 10,000 iterations, 50 times
• 1,000 iterations, 100 times
• 100 iterations, 500 times

I wanted to measure the difference in constant and variable comparisons. When I refer to an integer constant, I'm referring to a test like this:

<cfif myVar IS 1>

versus a variable test that would be a test like this:

<cfset myConstant = 1>
<cfif myVar IS myConstant>

For the Boolean tests I added the common construct of:

<cfif myVar>

to see if it offers any speed advantages besides less typing and being easier to read. This is such a common way of performing a Boolean test that even if it is close to being the fastest, many people would consider the readability to be more important than tiny speed improvements.

Tables 1-6 show the best result highlighted in bold print. Times shown are average times in milliseconds for the number of iterations indicated, averaged over the loop count times.

Note that in Table 1 the traditional "myVar IS value" and "myVar EQ value" have nearly identical speeds that are much faster than the "NOT Compare" and "Find" constructs. For all integer comparisons the traditional coding style is the fastest. Using a constant instead of a variable is about 19% faster, so use a constant if you can.

"NOT Compare" is the preferred comparison method for string constants and strings, despite "Find(myvar,value)" being slightly faster (see Table 2). The reason is that Find can't guarantee an exact match unless you also compare the string lengths, which would really slow you down. After all, comparing two strings is really what the Compare function is designed to do, so it follows that it should be the fastest method for string comparisons.

The Boolean constant I used was TRUE. I didn't expect this result. The construct <cfif myvar> was not the fastest Boolean comparison method. The common "myvar IS value" was faster almost every time; "myvar EQ value" virtually tied for the best times and in one case was the fastest method. Compared to the constant, TRUE was from 10% to 35% faster than using a Boolean variable set to TRUE (see Table 3).

Even though <cfif myvar> wasn't the fastest, many people will probably consider the readability benefit enough to take a 7% speed penalty compared to myVar EQ value. If you use a Boolean constant test compared to <cfif myvar>, the penalty is 20% to 25%. You have to decide whether the page processing time needs every ounce squeezed out of it. If it does, then pick the fastest method. If it's a page with limited access (an admin form, for example), then readability and maintainability would probably be your preference.

Bitwise Operations
Bitwise operators allow low-level bit operations that are typically necessary in assembly language. Bitwise operators are commonly used to manipulate flags, but Bit Shift Left is often touted as being the fastest way to multiply an integer by 2. Shifting the bits left one place in binary multiplies the number (integers only) by 2 in the same fashion that shifting a base 10 number left one multiplies it by 10. For example, 11 base 10 shifted to the left becomes 110. In modern C compilers the optimizer will automatically rewrite integer multiplys by 2 to a bit shift left; in CFML, however, our Bitwise Shift Left operator asks us how many places we want to shift. This added overhead actually makes the CFML bit shift left slower than simply writing i = i * 2, which was 11% to 21% faster than the BitSHLN function. Table 4 shows the speed measurements for the bitwise shift left versus multiplying a number times 2.

Since we have an operator that does ask us how many bits to shift left, I wondered if the performance would be closer for multiplys times 4 or 8. The simple method ranges from 18% to 25% faster. Table 5 shows the results of that test.

Another common task in a CFIF statement is to determine whether a number is even or odd (see Table 6). This is useful when applied to the currentrow in a query output to alternate the colors of the rows. The question is what's the best way to determine if currentrow is even or odd. Let's try using the bitwise AND operator and compare that to using the MOD function.

Hmm. That's an odd result. Using the CFML BitAnd function, except for a very small number of iterations, was about 16% slower than using MOD. For other programming languages bitwise operators are indeed faster than using MOD. For CFML however, stick to the MOD function.

Testing for Existence
Another very common CFIF task is to test for the existence of a variable. ParameterExists has been deprecated in favor of IsDefined, but just the same I wondered what the speed differences between these two functions were. Table 7 provides the test results.

As you can see, there's practically no difference between the two functions in terms of speed. We can feel secure in knowing that IsDefined() doesn't impose any performance penalty compared to the older ParameterExists.

Summary
Distilling the data in the tables, I generalized the results to the CFIF usage guidelines in Table 8.

Comparing to a constant is always faster than comparing to a variable. The speed advantage can exceed 35%, but mostly ranged from 10% to 20% faster.

For a Boolean test, using myVar IS value was the fastest. It's common to see <cfif myVar> in code, and you may still want to continue using that for readability purposes. If you do, understand that you're paying a 7% to 25% penalty for that readability.

For string comparisons the "NOT Compare" construct was the most efficient, which makes sense since that's what that function is designed to do.

We should continue using the more widely used MOD function instead of what our intuition might tell us regarding BitAnd to test for even numbers.

We have only one approved function to test for existence. The older ParameterExists function is still in the language, but only for backwards compatibility. Speedwise, the two functions are nearly identical, so use the current IsDefined function.

These test results are valid only for my situation. Yours is probably different. I have no idea if these numbers are similar for Linux, Solaris, or even other versions of CF or Windows. The only accurate way for you to know is to run your own tests.

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Figure 6
• Figure 7
• Figure 8