I was working on a CFC early this morning (5AM to be precise - don't ask my why - I wake up early) and was having an issue with performance. The CFC was a bug tracker (more info coming soon!) that would get slower as more bugs were added. I needed a nice way to quickly find out what parts of my code were the slowest. On a whim, I quickly wrote up the following custom tag:
<cfparam name="attributes.name">
<cfswitch expression="#thisTag.executionMode#">
<cfcase value="start">
<cfset begin = getTickCount()>
</cfcase>
<cfcase value="end">
<cfset total = getTickCount() - begin>
<cftrace var="total" text="Timer: #attributes.name#">
</cfcase>
</cfswitch>
To test, I then simply did:
<cf_timer name="block where I do foo">
someOperatation
</cf_timer>
By wrapping various pieces of my code with this tag, I was able to quickly diagnose the problem areas and correct them.
This code was based on a tag I saw in use in the CFAdmin for MX. This code was written by Mike Nimer of Macromedia. When I mentioned to him that I was going to blog this, he let me know that his tag still existed! So, if you don't mind using an unsupported tag, try cfimporting timer from the /cfide/administrator/cftags folder.
<cfimport taglib="/CFIDE/administrator/cftags" prefix="tags">
This tag tags two attributes, inline, which defaults to true, and message, which is the label. If you set inline to false, you will have to manually edit a debug template in order to get the data. It will be accessible in qEvents using a type = 'Timer'. (Did you know you could write your own debug templates for MX?)
Archived Comments
Raymond, can you expand on the last cfimport tag please?
Sure, once you import it, you would call the tag using this syntax (I don't think I allow brackets here, so pretend)
tags:timer
foo
/tags:timer
Gotcha, thanks.
If you are using CFMX you can also use cftrace. It will give you the execution time between each set of cftrace tags.