> This hack definitely works. As long as you're willing to pay the overhead
> for the method call, it's essentially equivalent to asking Log4J whether
> or not debugging output is enabled, which does something similar (but asks
> the instantiated logger object, instead of being a static method).
I'm not sure if Log4j has an accesible boolean like this (maybe it does, haven't used
it yet), and if it was accessible it would
reduce the gc load at the expense of some readibility of the source. The boolean
check is relatively efficient in comparison to the
function calls typically used in log messages (usually concat a string with some
computed value after unkown work).
I've run into problems with gc before and I tend to limit creation of extra objects.
Ever run most log packages under a profiler
and seen how many strings are created/destroyed on a regular basis? The code
log("my message that I think is import" + myVar.computeValue());
does unknown for myVar.computeValue() and then there is the creation of a
StringBuffer, the concat, and the toString on the
StringBuffer. All this for a line that may not be used except in high debug levels.
Try doing that in a critical peice of code and
watch performance go to hell quickly. On time critical code this gc time hurts. Don't
even start me talking about fun in the gc
with largs Maps. Can we say 90 second gc pauses every 2 minutes?
Does anyone know if Log4j has a boolean method to check whether debugging is on/off?
Jonathan
