I thought the consensus was to use the guarding when constructing the message parameter is expensive or when the log statement is called frequently or within a loop, but that otherwise it's not worth the extra clutter in the code to save a few nanoseconds. On 2/16/2009 4:47 AM, Heiko W.Rupp wrote: > Hi, > > this email is just for the records and summarizes a discussion we had > lately: > > our server and agent are logging at INFO level by default. > > So all log.debug() is not hitting the logfile, but still the > arguments of log.debug() are > evaluated(*) even if the logger decides later on to throw them away > and new objects > might be created, which hits performance and stresses the garbage > collector. > > Can we please (in the future) guard those log.debug() calls by if > (log.isDebugEnabled()) (or equivalent) > to save on evaluation of the argument, calling the logger and object > creation? > > One needs still to be careful to do the log.isDebugEnabled() not > within tight loops, but outside > > Example: > boolean shouldLog = log.isDebugEnabled(); > for (int i = 0; i< 1000; i++) { > .... > if (shouldLog) > log.debug( i + ... ); > } > > *) This might be no big deal for log.debug("hello world"), but > sometimes stuff that > calls into the database - and actually, that can be triggered by > a simple toString() call, if the implementation of toString() also > shows other > Entities hanging on the the one to print out. > > Or in the past (different employer) that was doing some complex > calculation > over a network of connected entities - here everything was in Memory, > but all > the objects where BigDecimal and just logging created dozens of Objects. > > Running with and without log.debug() made a factor of 2-3 in the > runtime of > the routine. > > > Heiko > _______________________________________________ jopr-dev mailing list jopr-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jopr-dev