While reviewing reports on Lucee's Dev Forum regarding performance differences between using an application-based CFC singleton and a global UDF, I thought I'd release our replacement for Adobe's CFTimer that I wrote back in 2013.
No more editing "Debugging IP Addresses"
If you wanted to use the built-in CFTimer function, Adobe required devs to specifically add their current IP address to the list of debugging IP addresses. This is inconvenient given that the task that it performs shouldn't really require special security... unless it's possible that Adobe's implementation of it could be compromised somehow. (Not sure, just guessing as I can't see any reason why this function requires special rules when you should be able to pass an option to suppress output under desired conditions.) Some third-party developers may not have access to CFAdmin or admin-based API functions, so they are left without any options other than to manually capture and output getTickCount(). (NOTE: I did have rules to pass a list of AllowedIPs, but the filter required a ipUtils.cfc library that is not available for public release yet due to third-party dependencies.)
Not Supported: Type="Debug"
I don't believe that developers have any way of influencing or adding to the output of Adobe's debug output. I used debug mode "once" to see what it did and then immediately disabled it and never bothered to use it again. (It can break too much if it is blindly enabled server or application-wide.)
Introducing nanoTime (already installed w/java.lang.system)
I didn't want to be required to loop over thousands or millions of iterations to compare performance differences, so the addition of nanoTime proved to be extremely beneficial as it provides accuracy down to the "one billionth of a second". It's not perfect, but it is at least an option.
Check out the differences between nanoTime and using millesconds.
Java System.nanoTime() vs System.currentTimeMillis
https://www.geeksforgeeks.org/java-system-nanotime-vs-system-currenttimemillis/
Use as CFScript
This can be called within CFScript by calling it using the following syntax.
cf_timer(type="outline", label="My timer test", nano=true){
performAnythingThatYouWantToMeasure();
}
Anyway, here's the CFTag. Enjoy!
https://gist.github.com/JamoCA/905c21d434cbef10b03cf799f9b93f16
Top comments (1)
Cool tool, James. I've added a feature request related to this. More in a moment.
FWIW, if it may not be clear to some, a design goal of that original cftimer (added in CF7) was indeed that it WAS intentionally tied to the CF Admin debugging feature, such that if it was enabled then like that debugging output the timer info was only shown to those on the IP address list (for better or worse).
Conversely, one could even leave the cftimer in the code in prod (where one might conceivably not enable debugging output) and they would not need to remove it.
I guess what you're saying is that it should have offered a way to run even with debugging disabled, and thus regardless of the client making the request being in the debug ip list. That's a fair point. They could have added that as an attribute to the tag (or arg to the script equivalent).
I suspect there was not much call to it, because really I bet 99% of CF devs don't even realize the feature is there, since CF7 about 20 years ago. So few may have been pressed to consider what you've raised. I just checked, and I see no one has filed a feature request for it, so I just did. :-)
tracker.adobe.com/#/view/CF-4214324
I realize I may not say what you would have, but you can certainly add a comment. And interested readers here can at least a vote if they think the idea may help.
Of course, until Adobe may address it, at least folks who find this post and code of yours can use this instead. And I added a comment pointing folks here.
Thanks for the efforts.