> "computationally expensive", i.e., concatenating
strings
Actually, no. I would not consider concatenating
strings to be computationally expensive (unless we're talking a plethora of
strings). A better example might be invoking a web service to
retrieve a particular value that you wish to log. If the level at which
the message will be logged isn't even enabled, then there is no need to invoke
the web service to retrieve the value.
"computationally expensive", i.e., concatenating strings
From: Matthew Brown [mailto:[EMAIL PROTECTED]
Sent: Friday, November 18, 2005 10:19 AM
To: Log4NET User
Subject: Re: Checking IsDebugEnabled before calling Debug()?
On 11/18/05, Castrianni, Chris {PBSG} < [EMAIL PROTECTED]> wrote:Good morning Tom,
My understanding is that you should use IsXXXEnabled for situations
where "message" is computationally expensive to create.
--Chris
-----Original Message-----
From: Tom Nichols [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 18, 2005 8:50 AM
To: [email protected]
Subject: Re: Checking IsDebugEnabled before calling Debug()?
Hi,
I was going through the examples and saw this:
// Log a debug message. Test if debug is enabled before
// attempting to log the message. This is not required but
// can make running without logging faster.
if (log.IsDebugEnabled ) log.Debug("This is a debug message");
My question is, why not just check this in LogImpl.Debug() , i.e.
virtual public void Debug(object message)
{
if( this.IsDebugEnabled ) Logger.Log(ThisDeclaringType,
m_levelDebug, message, null);
}
And then of course do the same for DebugFormat, Info, Warn, etc. etc.
I haven't dug much into the code but I'm interested in using the
framework. It just seems to me that if you really get a performance
enhancement from testing if IsDebugEnabled before calling it, it would
make more sense to save that step everywhere you make that Debug()
call in paractice.
I'm guessing there's a good reason why, but could someone tell me?
Thanks.
-Tom
