Or a more ambitious option is for the Log instances to register (weakly) with some registry that will update the instance variables if the logging configuration changes. This will allow a totally dynamic logging configuration but remain very fast.
Either approach should speed things up a bit if that performance boost is required. Plus this can all be pluggable.
On Wednesday, August 13, 2003, at 05:22 pm, Berin Loritsch wrote:
To be honest, I think we are overthinking this a bit. Very rarely does the
logging levels change at runtime. In fact many logging toolkits cache the
log level as a final variable to help the JIT inline and optimize out the
whole block.
In every project I have worked on, the logging levels remained constant from
component init time to destruction. The only time a logging level could or
would change is if the change was detected when the component was reloaded.
Effectively, in most cases this meant that the whole system came down before
the configuration would change.
Why add more difficulty to a simple solution?
The isXEnabled() methods are fast, and are usually quicker than one
concatenation. They do become the "bottleneck" when there is no concatenation
at all.
For example:
if ( m_logger.isDebugEnabled() ) { m_logger.debug( "test message" ); }
is both slower and more cumbersome than this:
m_logger.debug( "test message" );
However, as soon as you add in one concatenation with a variable the test
becomes valuable again:
if ( m_logger.isDebugEnabled() ) { m_logger.debug( "processing the component: " + componentName ); }
Also note that concatenating constants is something that most compilers do
anyway so that is not an issue for runtime performance. IOW:
"test" + " " + "message" == "test message"
Anything more than this is simply adding too much complexity for little or no
gain.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
James ------- http://radio.weblogs.com/0112098/
