logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Stauffer <jstau...@spscommerce.com>
Subject RE: Which Way of "Extending" Gives Fastest Performance
Date Thu, 22 Apr 2004 16:51:11 GMT
Is the call to isDebugEnabled actually significant?

James Stauffer

-----Original Message-----
From: Robert Pepersack [mailto:rpepersack@mdinsurance.state.md.us] 
Sent: Thursday, April 22, 2004 11:49 AM
To: Log4J Users List
Subject: Re: Which Way of "Extending" Gives Fastest Performance

You could create a class boolean variable that is set once by 
isDebugEnabled().  Then you could say:

private boolean debug = logger.isDebugEnabled();

In you method code you could say:

if (debug) cat.debug(myObject.showState());

This would make it so that you only call isDebugEnabled() once in each

At 11:54 AM 04/22/2004 -0400, you wrote:
>This is a little off from the original question, and note that we also
>haven't touched any of our logging code in quite a while, but:
>We found that we had to address some performance problems where there 
>an insignificant cost to creating the string that we were going to send to 
>For example, you might have:
>    cat.debug(myObject.showState());
>or some such thing, and the issue is that even if debug logging is
>disabled, the call into cat.debug() is still made, which means the call to 
>myObject.showState() is also made, even if the results from showState() 
>are in fact never used.
>We handled this by wrapping all of logging statements (well, at least
>debug ones, I think) in a conditional, like this:
>   if (cat.isDebugEnabled()) cat.debug(myObject.showState());
>to avoid that overhead.
>I was never really happy with this.  I suppose some sort of helper 
>might have made more sense... or is there a better way now to deal with
>James Stauffer wrote:
>>Do you know that logging has a significant effect on your current 
>>performance?  If it only takes 0.01% of CPU time then it doesn't 
>>really matter.
>>James Stauffer
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org

Bob Pepersack

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message