[jopr-dev] Logging ...

[John Mazzitelli]

That's my philosophy.

Ian Springer wrote:
> I thought the consensus was to use the guarding when constructing the 
> message parameter is expensive or when the log statement is called 
> frequently or within a loop, but that otherwise it's not worth the 
> extra clutter in the code to save a few nanoseconds.
>
> On 2/16/2009 4:47 AM, Heiko W.Rupp wrote:
>> Hi,
>>
>> this email is just for the records and summarizes a discussion we had 
>> lately:
>>
>> our server and agent are logging at INFO level by default.
>>
>> So all log.debug() is not hitting the logfile, but still the 
>> arguments of log.debug() are
>> evaluated(*) even if the logger decides later on to throw them away 
>> and new objects
>> might be created, which hits performance and stresses the garbage 
>> collector.
>>
>> Can we please (in the future) guard those log.debug() calls by if 
>> (log.isDebugEnabled()) (or equivalent)
>> to save on evaluation of the argument, calling the logger and object 
>> creation?
>>
>> One needs still to be careful to do the log.isDebugEnabled() not 
>> within tight loops, but outside
>>
>> Example:
>> boolean shouldLog = log.isDebugEnabled();
>> for (int i = 0; i< 1000; i++) {
>>     ....
>>        if (shouldLog)
>>         log.debug( i + ... );
>> }
>>
>> *) This might be no big deal for log.debug("hello world"), but 
>> sometimes stuff that
>> calls into the database - and actually, that can be triggered by
>> a simple toString() call, if the implementation of toString() also 
>> shows other
>> Entities hanging on the the one to print out.
>>
>> Or in the past (different employer) that was doing some complex 
>> calculation
>> over a network of connected entities - here everything was in Memory, 
>> but all
>> the objects where BigDecimal and just logging created dozens of Objects.
>>
>> Running with and without log.debug() made a factor of 2-3 in the 
>> runtime of
>> the routine.
>>
>>
>>   Heiko
>>
>
> _______________________________________________
> jopr-dev mailing list
> jopr-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jopr-dev