geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@coredevelopers.net>
Subject Re: Logging code and Garbage Collection
Date Wed, 13 Aug 2003 16:39:51 GMT
I believe it is silly to be worrying about such things at this point.  
If there is a real problem here, then lets address it else, lets save 
this convo for later.

--jason


On Wednesday, August 13, 2003, at 11:33  PM, Gareth Bryan wrote:

> I think runtime swapping of log levels is a very powerful feature: we
> should have this feature if it is at all feasible.
>
> Also:
>
> I have written loggers in the past which fail **very** quickly if a
> particular level is not enabled.  The logger implementation uses a
> delegate mechanism whereby when setLogLevel() is called (ie during 
> init),
> any log levels which are not operational have their request mapped
> through to a NullLogger.  Thus the only overhead of calling a log 
> method
> for a level which is not enabled is the method location + stack 
> overhead.
>
> I'd be suprised if something similar doesn't happen for log4j impl;
> though I'm no expert on log4j
>
> Regards,
>
> Gareth
>
> On Wed, 13 Aug 2003 12:22:04 -0400, "Berin Loritsch"
> <bloritsch@apache.org> said:
>> 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
>>
> -- 
>   Gareth Bryan
>   garethbryan@fastmail.fm
>
> -- 
> http://www.fastmail.fm - Does exactly what it says on the tin
>


Mime
View raw message