geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [Logs] Re: Logging code and Garbage Collection
Date Thu, 14 Aug 2003 22:59:28 GMT
Have you tested this to find out how much performance you save by doing 
this? If there's not any numbers to show how well it is before and 
after, and that it was in the bottleneck of the system, then it's 
premature optimisation.

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

> On Thursday, August 14, 2003, at 05:08 PM, Alex Blewitt wrote:
>> I fear that this is a tad pointless; the logs in Log4J are going to 
>> do this anyway, and not cache the log values.
> I disagree that this is pointless.  We need something for today (it 
> took about a half hour), and when they get their stuff working, we 
> remove my code.

I didn't know it was broken, my mistake.

>> 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 ...
> Duh.  We all agree on that.  But when you have debug("my single string 
> message") there is not need to wrap, and when you do need the 
> isDebugEnabled() call, it will be very fast.

I think the consensus was to always use isDebugEnabled() anyway, and if 
it is being used more than once in a method then it is held in a local 
variable, as opposed to having a caching framework ...

>> So the problem is still going to exist, albeit a factor slower since 
>> it's going through this caching log :-/
> Agree, that is what caching is all about.

Sorry, my point was that I expected your caching code to slow it down; 
IMHO it will run faster without it. Caching a boolean value is an 
incredibly small factor of performance boost, and you've got an extra 
method call in your chain. When I was playing around with benchmarks, 
the method call was the expensive bit, not the boolean value access.

So, if you've got numbers to say that this makes a noticeable 
difference in a big piece of code and that it helps the bottleneck, 
great. But if not, we may not need to use it.


View raw message