Testing ColdFusion Custom Tag Processing Overhead

Posted November 29, 2007 at 11:36 AM

Tags: ColdFusion

The other day, when blogging about my final thoughts on Data Type vs. Data Value validation, my idea for a ColdFusion custom CFParam tag got a little traction. One of the thoughts exchanged was about the overhead that would come with the use of a ColdFusion custom tag. I am not too familiar with what overhead would be incurred, so I thought I would do a little speed testing.

The idea with this CFParam ColdFusion custom tag is that internally, we are wrapping the CFParam tag in a CFTry / CFCatch block to catch any failed type validation. Then, in the CFCatch block, we are setting the target variable equal to the default value of the failed tag:

 Launch code in new window » Download code as text file »

  • <!--- Kill extra output. --->
  • <cfsilent>
  •  
  • <!---
  • Try to Param the variable. For this experiment,
  • we are going to assume that these ATTRIBUTES
  • always defined.
  • --->
  • <cftry>
  • <cfparam
  • name="CALLER.#ATTRIBUTES.Name#"
  • type="#ATTRIBUTES.Type#"
  • default="#ATTRIBUTES.Default#"
  • />
  •  
  • <!--- Catch paraming errors. --->
  • <cfcatch>
  •  
  • <!---
  • Just set the variable to the given default
  • value that was passed in.
  • --->
  • <cfset "CALLER.#ATTRIBUTES.Name#" = ATTRIBUTES.Default />
  •  
  • </cfcatch>
  • </cftry>
  •  
  •  
  • <!--- Exit tag. --->
  • <cfexit method="exittag" />
  •  
  • </cfsilent>

This ColdFusion custom tag (param.cfm) does no attribute validation or anything like that. I am trying to keep it as simple as possible to really just test the overhead of the custom tag usage, not the validation logic.

When testing the overhead, I wanted to run two different scenarios: worst case and best case. In the worst case, all of the CFParam tags will fail and throw exceptions. In the best case, none of the tags will fail or throw exceptions.

Worst Case Scenario

In the worst case scenario, we are making sure that every paramed variable will fail its type validation. In the first CFTimer, we are using our ColdFusion custom tag and in the second CFTimer, we are using inline error handling:

 Launch code in new window » Download code as text file »

  • <!---
  • Set the number of variables we are going to be paraming
  • in our speed tests.
  • --->
  • <cfset intCount = 500 />
  •  
  •  
  • <!---
  • For our first run, we are going to use a ColdFusion custom
  • tag to param a variable. If the internal CFParam tag fails,
  • then the custom tag will take care of setting the default.
  • We are doing this to see what kind of overhead the custom
  • cfparaming tag adds to processing.
  • --->
  • <cftimer
  • type="outline"
  • label="ColdFusion Custom Tag">
  •  
  • <!--- Loop over a number of variables to param. --->
  • <cfloop
  • index="intI"
  • from="1"
  • to="#intCount#"
  • step="1">
  •  
  • <!---
  • Set a variable value that we know will fail the
  • following CFParam tag.
  • --->
  • <cfset FORM[ "varA#intI#" ] = "" />
  •  
  •  
  • <!--- Param the value using ColdFusion custom tag. --->
  • <cf_param
  • name="FORM.varA#intI#"
  • type="numeric"
  • default="0"
  • />
  •  
  •  
  • #FORM[ "varA#intI#" ]#
  •  
  • </cfloop>
  •  
  • </cftimer>
  •  
  •  
  • <!---
  • Now, we are going to param a bunch of variables in exactly
  • the same way that the first timer did; only, this time, we
  • are going to do the try / catch inline so that no custom
  • tag is needed.
  • --->
  • <cftimer
  • type="outline"
  • label="Inline CFTry / CFCatch">
  •  
  • <!--- Loop over a number of variables to param. --->
  • <cfloop
  • index="intI"
  • from="1"
  • to="#intCount#"
  • step="1">
  •  
  • <!---
  • Set a variable value that we know will fail the
  • following CFParam tag.
  • --->
  • <cfset FORM[ "varB#intI#" ] = "" />
  •  
  •  
  • <!--- Param the value using CFTry / CFCatch. --->
  • <cftry>
  • <cfparam
  • name="FORM.varB#intI#"
  • type="numeric"
  • default="1"
  • />
  •  
  • <!---
  • Catch the paraming value and then set the
  • variable to be the same as the default.
  • --->
  • <cfcatch>
  • <cfset FORM[ "varB#intI#" ] = 1 />
  • </cfcatch>
  • </cftry>
  •  
  •  
  • #FORM[ "varB#intI#" ]#
  •  
  • </cfloop>
  •  
  • </cftimer>

Running this code 5 times, I get the following times:

CF_Param ColdFusion Custom Tag

9,438 ms
1,0328 ms
9,672 ms
9,406 ms
9,375 ms

Average: 9,643 ms

Inline Error Handling

8,671 ms
8,875 ms
9,281 ms
8,687 ms
9,015 ms

Average: 8,905 ms

So, it looks like in the worst case scenario in which exceptions are always being thrown, there is definitely some overhead to the ColdFusion custom tag, but I would say not crazy, or rather, not too much overhead considering the high number of exceptions.

Best Case Scenario

Now, let's look at the best case scenario in which we never thrown an exception. Remember, we only expect CFParam exceptions to be generated when someone has messed with the XHTML or the URL. For 99% of our users, who are good people, we don't expect to have to handle exceptions. As such, the best case scenario will demonstrate more of what the average user will experience:

 Launch code in new window » Download code as text file »

  • <!---
  • Set the number of variables we are going to be paraming
  • in our speed tests.
  • --->
  • <cfset intCount = 500 />
  •  
  •  
  • <!---
  • For our first run, we are going to use a ColdFusion custom
  • tag to param a variable. If the internal CFParam tag fails,
  • then the custom tag will take care of setting the default.
  • We are doing this to see what kind of overhead the custom
  • cfparaming tag adds to processing.
  • --->
  • <cftimer
  • type="outline"
  • label="Non-Failing ColdFusion Custom Tag">
  •  
  • <!--- Loop over a number of variables to param. --->
  • <cfloop
  • index="intI"
  • from="1"
  • to="#intCount#"
  • step="1">
  •  
  • <!--- Set a variable value that we NOT fail. --->
  • <cfset FORM[ "varC#intI#" ] = 0 />
  •  
  •  
  • <!--- Param the value using ColdFusion custom tag. --->
  • <cf_param
  • name="FORM.varC#intI#"
  • type="numeric"
  • default="0"
  • />
  •  
  •  
  • #FORM[ "varC#intI#" ]#
  •  
  • </cfloop>
  •  
  • </cftimer>
  •  
  •  
  • <!---
  • Now, we are going to param a bunch of variables in exactly
  • the same way that the first timer did; only, this time, we
  • are going to do the try / catch inline so that no custom
  • tag is needed.
  • --->
  • <cftimer
  • type="outline"
  • label="Non-Failing Inline CFTry / CFCatch">
  •  
  • <!--- Loop over a number of variables to param. --->
  • <cfloop
  • index="intI"
  • from="1"
  • to="#intCount#"
  • step="1">
  •  
  • <!--- Set a variable value that we NOT fail. --->
  • <cfset FORM[ "varD#intI#" ] = 1 />
  •  
  •  
  • <!--- Param the value using CFTry / CFCatch. --->
  • <cftry>
  • <cfparam
  • name="FORM.varD#intI#"
  • type="numeric"
  • default="1"
  • />
  •  
  • <!---
  • Catch the paraming value and then set the
  • variable to be the same as the default.
  • --->
  • <cfcatch>
  • <cfset FORM[ "varD#intI#" ] = 1 />
  • </cfcatch>
  • </cftry>
  •  
  •  
  • #FORM[ "varD#intI#" ]#
  •  
  • </cfloop>
  •  
  • </cftimer>

Running this code 5 times, I get the following times:

CF_Param ColdFusion Custom Tag

735 ms
735 ms
734 ms
735 ms
812 ms

Average: 750 ms

Inline Error Handling

31 ms
15 ms
16 ms
31 ms
16 ms

Average: 21 ms

As you can see here, when we run into a best case scenario, the difference in performance between the CFParam tag and our ColdFusion custom tag is much more noticeable. Of course, this is for 500 CFParam executions, which is much greater than any normal page should ever have. With 1,2,3 or even 10 CFParam tags, the execution time will not be noticeable. However, on larger systems, this might not be a risk worth taking? Depends on how much optimization you want vs. readability / maintainability.

Download Code Snippet ZIP File

Comments (4)  |  Post Comment  |  Ask Ben  |  Permalink  |  Other Searches  |  Print Page




Adobe ColdFusion 8.0.1 Update - Helping Programmers To Be Signifanctly Less Girlie - Download ColdFusion 8 Update 8.0.1 Now.

Reader Comments

That stinks. So you end up with a greater performance hit when the variable is valid. I thought it would be the opposite. In my applications, an invalid value is the exception, not the rule.

Posted by Brad Roberts on Nov 29, 2007 at 12:55 PM


@Brad,

Yeah, I am not sure how I feel about this. On one hand, there are so few variables on a page that need to be paramed (I think 30 was my biggest page EVER). But on the other hand, not sure how this scales. It might get slower and slower with large applications and concurrent requests. That is where my speed tests don't give data.

Also, this is slightly faster in ColdFusion 8, but barely.

Posted by Ben Nadel on Nov 29, 2007 at 1:02 PM


Just out of curiosity, is this code being used in the model, controller, or view of an app?

Posted by Andrew Powell on Nov 29, 2007 at 1:12 PM


@Andrew,

Is is the Controller. When the FORM is submitted back to page, the controller will take the form data and set it into the model and then pass it off to the service layer (at least, that is how I have it in my experiments).

Posted by Ben Nadel on Nov 29, 2007 at 1:15 PM


Post Comment  |  Ask Ben


Home   |   Web Log   |   ColdFusion   |   Projects   |   Resume   |   Job Form   |   Search   |   Contact
Epicenter Consulting - Custom Software Solutions for Business Evolution HostMySite.com - The Leader In ColdFusion Hosting