On Wednesday, August 13, 2003, at 04:26 pm, Jeremy Boynes wrote:
From: Jason Dillon [mailto:[EMAIL PROTECTED]
I would depend on how it was cached. If you mean if a method traces or debugs more than once, it should definitely create a local variable to cache if the level is enabled, but if you mean for a larger scoped cache, this could make it hard to debug a running server, as you can always tweak the active levels at runtime.
Local variable, a given.
The thing is, the isXEnabled() method gets called a gazillion times to
detect the one time that the level was bumped up, which happends very
infrequently. I'm assuming this goes through a synchronized block as
well, add yet more ns to the call. The runtime feature is useful but has
a price.
Some form of lazy caching scheme may be appropriate, provided checking invalidation is quicker than the call to isXEnabled().
Since the isXEnabled() methods are so simple, we could have a volatile, boolean flag cached representing the state of whether or not logging is enabled so that there's no synchronizing and the implementation is very fast (and inlined) by the JVM.
Using log4j code names here - each Logger could register (with a weak reference) with the LoggerRepository so that when the logging changes, the Logger's could be notified ('pushed') to update their cached flags. Sure it'd use a bit more RAM (could use 1 byte per logger if need be or 4 boolean flags for simplicity) though it should be much faster. Right now each isXEnabled() calls a method on a shared object which is synchronized (LoggerRepository.isDisabled()).
I wonder if the log4j folks thought of this?
We should remember though - premature optimisation is the root of all evil - do we have the test metrics to prove this is the problem? I guess hacking together a quick test case should be quite easy of 2 equivalent commons-logging implementation - one using log4j and one using a cached boolean.
James ------- http://radio.weblogs.com/0112098/
