geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: [Logs] Re: Logging code and Garbage Collection
Date Thu, 14 Aug 2003 22:08:51 GMT
I fear that this is a tad pointless; the logs in Log4J are going to do 
this anyway, and not cache the log values.

The big problem was that when doing log("String" + value + "message") 
is that the string concatenation is always done, regardless of whether 
the log level was enabled or not. That is why it was desirable to 
surround with the if() statements in the first place ...

So the problem is still going to exist, albeit a factor slower since 
it's going through this caching log :-/

Alex.

On Thursday, Aug 14, 2003, at 23:02 Europe/London, Dain Sundstrom wrote:

> I have just checkin in a proof of concept CachingLog4jLog.  This 
> commons log implementation caches the values of the trace, debug, and 
> info enabled flags.  The flags are update on a periodic basis by a 
> single java.util.Timer.  The period is currently hard coded to 3 
> minutes, but if people like this I can add a management interface to 
> it.
>
> The warn, error and fatal levels are hard coded to true as log4j does 
> not even expose a isXXXEnabled for these levels.  The internal 
> implementation of the trace, debug, and info methods do an explicit 
> level check before delegating the the log4j logger.  For example:
>
>     public void info(Object message) {
>         if (infoEnabled) {
>             logger.log(FQCN, Priority.INFO, message, null);
>         }
>     }
>
>
> -dain
>
> On Thursday, August 14, 2003, at 03:14 AM, Alex Blewitt wrote:
>
>>
>> On Thursday, Aug 14, 2003, at 06:31 Europe/London, Pasi Salminen 
>> wrote:
>>
>>> Putting my administrator hat on, I must say that I don't like 
>>> application servers
>>> which do not enable change of logging level at runtime.
>>
>> Though personally I've not come across this before, I can see that it 
>> would be a desirable thing to have.
>>
>>> Berin Loritsch wrote:
>>>
>>>> For example:
>>>>
>>>> if ( m_logger.isDebugEnabled() )
>>>> {
>>>>      m_logger.debug( "test message" );
>>>> }
>>>>
>>>> is both slower and more cumbersome than this:
>>>>
>>>> m_logger.debug( "test message" );
>>
>> I will agree that there is more code. But bear in mind that w/o the 
>> debugging guard, the m_logger.debug("message") will almost certainly 
>> call m_logger.isDebugEnabled() (or access the boolean to do the test) 
>> anyway, so in the (common) case when debugging isn't enabled then 
>> IMHO it will make very little difference; possibly even run /faster/ 
>> with the guard.
>>
>> Bear in mind that 'is slower' and 'is faster' are only likely to be 
>> based on what we humans think; until you've actually got code that is 
>> running, and it is demonstrable that this is where the bottleneck is, 
>> then pre-optimisation isn't worthwhile.
>>
>> Alex.
>>
>>
>
> /*************************
>  * Dain Sundstrom
>  * Partner
>  * Core Developers Network
>  *************************/
>


Mime
View raw message