Possible off topic so feel free to tell me to stop... It has a cost in your time and added complexity. If someone new enters your project it will take them longer to figure our what is going on. Granted, that cost doesn't seem very great but why not use your time where you know it will actually provide a noticeable return. Some things I have learned from http://javaperformancetuning.com/ are don't tune unless you know where the problem areas are (your natural guess is almost certainly wrong) and don't tune without doing before and after testing (What looks like it may increase performance may actually decrease performance).
James Stauffer -----Original Message----- From: Robert Pepersack [mailto:[EMAIL PROTECTED] Sent: Thursday, April 22, 2004 1:24 PM To: Log4J Users List Subject: RE: Which Way of "Extending" Gives Fastest Performance I've never tried calling isDebugEnabled() again and again in the same class. I'm new to log4j, so I don't have a lot of code that uses log4j. It doesn't cost me anything to factor out the tests from the beginning. Every little bit of performance tuning (no matter how insignificant) helps when I have hundreds of threads executing simultaneously in my J2EE server. That's the point of my original question: Does anyone know which performs fastest (wrapping or extending)? At 12:42 PM 04/22/2004 -0500, you wrote: >If you don't know that it has any noticeable affect on your performance >than is that just wasted time? > >James Stauffer > > > >-----Original Message----- >From: Robert Pepersack [mailto:[EMAIL PROTECTED] >Sent: Thursday, April 22, 2004 12:21 PM >To: Log4J Users List >Subject: RE: Which Way of "Extending" Gives Fastest Performance > > >It shouldn't be significant. On page 41 of the book, Ceki says, "This >is an insignificant overhead because evaluating a logger takes less >than 1% of the time it actually takes to log. If a method contains >multiple log statements, it may be possible to factor out the tests." > >I factor out the tests, because I'm sensitive to performance. > > > >At 11:51 AM 04/22/2004 -0500, you wrote: > >Is the call to isDebugEnabled actually significant? > > > >James Stauffer > > > > > > > >-----Original Message----- > >From: Robert Pepersack [mailto:[EMAIL PROTECTED] > >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 class. > > > > > >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 was an insignificant cost to creating the string that we were > > >going to send to log4j. > > > > > >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 > > >object might have made more sense... or is there a better way now > > >to deal with > >this? > > > > > >dwh > > > > > > > > >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: [EMAIL PROTECTED] > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > >Bob Pepersack > >410-468-2054 > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > >Bob Pepersack >410-468-2054 > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] Bob Pepersack 410-468-2054 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
