Hi Brook, Cool, thanks for trying it out! I think you have it right on all counts.
If you're using cftrace/trace() and Firelogger/Firebug is not enabled then the custom trace tag will simply call the "native" CF trace code (trace_adobe.cfm). In this case there will be a little overhead as trace will log the value to cftrace.log, but otherwise not much else happens. AFAIK the native trace code does log to cftrace.log even when debug is disabled on the server. Of course you could easily change the custom trace.cfm to simply exit if Firelogger isn't active (just don't call adobe_trace.cfm). If you use the firelogger.cfc and its log() method directly, and Firelogger is disabled, then there is a small overhead just from instantiating the CFC (no idea how to quantify that), but otherwise it will simply return w/out doing much of anything. So the overhead would be very minimal in this case as well. Either of the above holds true whether or not debugging is enabled in CF admin. cftrace/trace() (including my custom version) only saves to debug info if debugging is enabled on the server. firelogger.cfc by itself doesn't save to debug info at all. You can still output messages to Firelogger console from within your code even if debug is disabled using either trace() or firelogger.log(). The main benefit to using cftrace/trace() is that if you move code to a server that doesn't have firelogger.cfc installed, it still works. You also keep the other options of cftrace, such as dumping the data inline and/or logging to a file. As for the overall CF debug output, it certainly carries a performance penalty. I definitely disable debugging on production servers and turn it on only when needed. I can't tell you exactly what impact it has, but the amount of information tracked by the debugger is potentially huge. The debug info--which templates, queries, traces, etc, have executed--is a (possibly giant) query that gets written-to every time an event happens, and it saves a ton of info about each event. I imagine it could incur a significant memory hit at the least. This happens whether or not Firelogger is enabled--the only way to disable that processing is to turn off debugging in CF admin. I don't know if it still collects all that info if your IP address doesn't match what is set up in "Debugging IP Addresses" (probably not, but need to test!). Hope that helps! Cheers, -Max -------- Original Message -------- Subject: Re: [ANNOUNCE] CF-FireLogger From: Brook Davies <[email protected]> To: cf-talk <[email protected]> Date: 1/27/2012 12:37 AM > > Hey Max, > > Got it installed (painless) and it looks cool. What I am wondering is > it seems like you advocate using trace() instead of console(). And > it sounds like if firebug/firelogger is not enabled, that no > debugging output would be sent. Is that true? If so, is there a > performance penalty to using this on a production server to track a > bug? Wouldn't any client that does not have the firebug/firelogger > combo and their IP added to the CF debugging IP list not get any > additional overhead? Does the trace tag have overhead when debugging > is not enabled? > > Just some thoughts.... > > Thanks again for a very cool extension and contribution to the > community! > > Brook > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:349637 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
