This content has been marked as final.
Show 5 replies
-
1. Re: log.isTraceEnabled() and performance
ataylor May 13, 2008 12:17 PM (in response to timfox)The trouble is with the second piece of code, changes to the log level at runtime might not get picked up. saying that I'd prefer to have the performance increase and maybe lose some logging.
-
2. Re: log.isTraceEnabled() and performance
trustin May 13, 2008 7:38 PM (in response to timfox)What about just not calling isTraceEnabled() and call log.trace() directly? It should perform better when the message is simple enough.
-
3. Re: log.isTraceEnabled() and performance
clebert.suconic May 13, 2008 7:59 PM (in response to timfox)That's terrible.
You would be doing lots of string concatenations to just throw them away on the limbo of the Garbage Collection.
Example:
log.trace("This is a concatenation of " + myObject + " with anthing such as = " + anInteger + " just to show how dumb strings are"); -
4. Re: log.isTraceEnabled() and performance
clebert.suconic May 13, 2008 8:01 PM (in response to timfox)ok.. I missed the "when the message is simple enough" part.
Still better to not call it when trace is not set IMO. -
5. Re: log.isTraceEnabled() and performance
timfox May 14, 2008 3:37 AM (in response to timfox)"clebert.suconic@jboss.com" wrote:
Still better to not call it when trace is not set IMO.
Yes, log.isTraceEnabled() has a significant overhead.
Actually in JBM 1.4 approx 3% of time was spent in log.isTraceEnabled() calls until we changed it to check a static flag "trace"! (Admittedly we had a lot of log.isTraceEnabled() calls).
Moral of the story: Don't assume that log.isTraceEnabled() (or log.isDebugEnabled()) is a fast call, and never put it in performance critical sections.