Welcome!

ColdFusion Authors: Yakov Fain, Maureen O'Gara, Nancy Y. Nee, Tad Anderson, Daniel Kaar

Related Topics: ColdFusion

ColdFusion: Article

Which Is Faster?

Which Is Faster?

Which is faster, <CFQUERY> or <CFLOOP>? Which is faster, CFML or <CFSCRIPT>? Which is faster... ? If you're a ColdFusion developer, chances are that you've asked (or have been asked) these questions and others like them.

So, Which Is Faster?
Okay, so which option is actually the faster one? Honestly? I'm not so sure. Once upon a time (pre-CF4) we were told that <CFLOOP> was very slow. Then (when CF4 shipped) we were told that <CFLOOP> had been optimized and outperformed <CFOUTPUT>. And now, well, CFMX changes everything. So, which is faster?

Of course, performance-related questions are legitimate. We all keep looking for ways to tweak just a little more oomph from our code. But the truth is that this is not just a CFML syntax concern; this affects all sorts of code, database calls, design considerations, reuse implementations, and more.

ColdFusion debugging helps us out a little here. Execution time (for a complete page or parts thereof) provides an invaluable peek under the CF covers. But for more granular performance comparisons, for detailed benchmarking, and for ascertaining definitive performance data, debug output falls a bit short.

Enter ColdFusion MX
Ever since ColdFusion MX shipped I've been trying to better understand exactly what the product is doing internally so as to be able to write better code. And like many of you, I've discovered that an interesting side effect of ColdFusion's new processing engine is that many of the tips and tricks I lived by don't really apply anymore; some have negligible effects on my code, and others are just plain wrong. So I created an application, a really simple performance comparison tool, using good old ColdFusion. This tool has proven so invaluable that I feel compelled to share it with you. Read on.

Measuring Execution Time
The key to measuring any execution time in ColdFusion is an intriguing little function named GetTickCount(). GetTickCount() takes no parameters, and returns a number that is, in and of itself, rather useless. So what makes GetTickCount() so intriguing? The number that GetTickCount() returns is a value in milliseconds, and invoking GetTickCount() exactly one second after a prior GetTickCount() invocation returns a value exactly 1000 times greater than the first returned value.

In other words, to determine exactly how long a line of code takes to execute, you could do the following:

<CFSET start=GetTickCount()>
... some CFML code ...
<CFSET end=GetTickCount()>
<CFSET executiontime=end-start>

Measuring a single execution yields no usable data - a single invocation may run faster or slower at any time based on lots of other factors (ColdFusion factors and otherwise). To really measure execution time, code must be executed repeatedly, and each iteration must be measured individually and stored. Then an average execution time can be determined by processing all of the saved values.

The simplest way to do this in ColdFusion is to loop through the iterations, saving each measurement to an array, perhaps like this:

<CFSET start=GetTickCount()>
...some CFML code...
<CFSET end=GetTickCount()>
<CFSET ArrayAppend(timings, end-start)>

Then to obtain the average execution time you could simply use:

#ArrayAvg(timings)#

Similarly, total execution time, slowest iteration, and fastest iteration could easily be determined using array functions like this:

Total: #ArraySum(timings)#
Slowest: #ArrayMax(timings)#
Fastest: #ArrayMin(timings)#

To compare the processing of two options you'd simply repeat this process twice (saving the data to two arrays, one for each option), and then compare the results.

Presenting Results
Detailed benchmarking data is useless unless it can be presented in a format that makes it clear and understandable. <CFCHART> (and related tags) makes it easy to plot the data in a highly usable and readable format.

<CFCHART> is usually used to chart database query results, but as this code snippet demonstrates, individual data points can be passed explicitly using the <CFCHARTDATA> tag. In this example, two arrays (named timings1 and timings2) are being charted in individual data series in a single chart. The inner loops loop from 1-100, and on each iteration, passes the appropriate array value (from both arrays) to <CFCHART>.

<!--- Graph it --->
<CFCHART FORMAT="flash"
SHOWMARKERS="no">
<CFCHARTSERIES TYPE="line"
SERIESLABEL="Option 1 Title"
SERIESCOLOR="red">
<CFLOOP FROM="1" TO="100" INDEX="i">
<CFCHARTDATA ITEM="#i#"
VALUE="#timings1[i]#">
</CFLOOP>
</CFCHARTSERIES>
<CFCHARTSERIES TYPE="line"
SERIESLABEL="Option 2 Title"
SERIESCOLOR="green">
<CFLOOP FROM="1" TO="100" INDEX="i">
<CFCHARTDATA ITEM="#i#"
VALUE="#timings2[i]#">
</CFLOOP>
</CFCHARTSERIES>
</CFCHART>
Putting It All Together
Over the past few months I've found myself using code much like what I described above over and over. So to make testing quicker and cleaner, I created the "Which is Faster?" application. The app is actually incredibly simple; the idea is as follows:
  • The two coding options (perhaps <CFLOOP QUERY=""> and <CFOUTPUT QUERY="">) are each placed in their own .cfm files. (I named mine loop.cfm and output.cfm).
  • Some tests may require the execution of code that is not part of the actual test (for example, to test <CFLOOP> and <CFOUTPUT> you'd need a query to be executed, but you'd not want it to be executed along with the <CFLOOP> and <CFOUTPUT> tags), so that code is placed in its own .cfm file. (I named mine query.cfm.)
  • A form prompts for the names of these files, descriptions, as well as the number of iterations to use when testing.
  • The form submits to a processing page that first includes the preprocessor page (if one was specified) and then loops as instructed, including each test file and saving the execution times to arrays, which are then used by <CFCHART> tags to chart the performance.

    For my own testing (to test <CFLOOP> versus <CFOUTPUT>) I used three files. Here they are:

    QUERY.CFM
    <CFQUERY DATASOURCE="exampleapps"
    NAME="emps">
    SELECT *
    FROM tblEmployees
    ORDER BY LastName, FirstName
    </CFQUERY>

    OUTPUT.CFM
    <CFOUTPUT QUERY="emps">
    </CFOUTPUT>

    LOOP.CFM
    <CFLOOP QUERY="emps">
    </CFLOOP>

    These are simple, crude, and not real-world at all. But they are perfect for this type of testing - you wouldn't want lots of other processing included, as that could skew the results.

    FORM.CFM (Listing 1) contains the code for the form, a simple HTML form as described above (see Figure 1). One checkbox worth noting is the "Exclude first iteration" option; as ColdFusion may have to compile the code on the first execution, you may not want to include that in the collected data (as it will skew the results, creating a much slower first value).

    PROCESS.CFM (Listing 2) processes the form. The code first uses <CFPARAM> and a series of <CFIF> statements to validate and prepare passed values. If a preprocessor file was specified, it is then executed. Next, if the "Exclude first iteration" option was checked, each included file is executed once (using <CFINCLUDE> tags) so as to force a compile if needed. Then comes the test itself; <CFLOOP> loops from 1 to the specified number of iterations and, within each iteration, both files are executed and the timings for each appended to one of two arrays (one for each test). Finally the results are displayed in five graphs (see Figure 2). The first shows the execution details, and the next four show total processing time, average iteration processing time, as well as fastest and slowest iteration processing time. (In case you were wondering why I used two arrays instead of a single two-dimensional array, these last four graphs are the reason; functions like ArraySum() and ArrayAvg() work on single dimensional arrays only).

    Where to Go from Here
    Of course, writing all this down has gotten me thinking. It would be nice if instead of just including files with <CFINCLUDE> the application would give you a choice and also allow:

    • <CFHTTP> calls to complete pages, local or remote
    • <CFINVOKE> calls to Web services or ColdFusion Components
    • <CFMODULE> calls to Custom Tags
    It's tempting to modify the app right now, but so as to get this column in, I'll leave this enhancement for you to work on. If you find the application useful and enhance it, please let me know.

    Conclusion
    So, which is faster, <CFLOOP> or <CFOUTPUT>? Answer: <CFLOOP> seems slightly faster, but there is so little difference it's essentially insignificant. Which is faster, CFML or <CFSCRIPT>? Answer: almost no difference (unless I ran ridiculously large tests, as in 10,000 assignments per iteration). Which is faster? Now you can find out yourself - and not just with CFML language elements, but whole blocks of functionality, pages, SQL statements, and more. Enjoy!

  • More Stories By Ben Forta

    Ben Forta is Adobe's Senior Technical Evangelist. In that capacity he spends a considerable amount of time talking and writing about Adobe products (with an emphasis on ColdFusion and Flex), and providing feedback to help shape the future direction of the products. By the way, if you are not yet a ColdFusion user, you should be. It is an incredible product, and is truly deserving of all the praise it has been receiving. In a prior life he was a ColdFusion customer (he wrote one of the first large high visibility web sites using the product) and was so impressed he ended up working for the company that created it (Allaire). Ben is also the author of books on ColdFusion, SQL, Windows 2000, JSP, WAP, Regular Expressions, and more. Before joining Adobe (well, Allaire actually, and then Macromedia and Allaire merged, and then Adobe bought Macromedia) he helped found a company called Car.com which provides automotive services (buy a car, sell a car, etc) over the Web. Car.com (including Stoneage) is one of the largest automotive web sites out there, was written entirely in ColdFusion, and is now owned by Auto-By-Tel.

    Comments (2)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.