Comments for Mediasoft

Comment on Don’t clutter your code with isDebugEnabled by FoX

FoX — Wed, 10 Jun 2009 06:48:37 +0000

That’s really the point in using the slf4j api, you don’t have to concatenate Strings unnecessarily.

I’ve performed some tests on the different approaches and it is clear that the overhead of using the slf4j API is minimal. Slf4j is only 16% slower than the isDebugEnabled approach when debug logging is turned off (Plain Log4J is about +15000% slower), so we are talking about a performance penalty of only 0,11ms on 1000 log statements. When debug logging is turned on, the slf4j approach is only 6.50% slower than using isDebugEnabled.

I’d choose for cleaner code and better readability than this minor performance impact. There are other points to worry about concerning performance, like database, business logic, sorting, pagination, etc.

Comment on Don’t clutter your code with isDebugEnabled by Vinod

Vinod — Wed, 10 Jun 2009 04:50:32 +0000

Without isDebungEnabled() code may look prettier but you have to pay the performance price. isDebugEnabled() takes far less time then a String construction for logging.

Comment on Don’t clutter your code with isDebugEnabled by rainwebs

rainwebs — Tue, 09 Jun 2009 23:32:22 +0000

The question to me is, do we really have a performance problem if the skip the if statement? The JVM optimization features and the faster processors let me tend to skip it for a better readability of the code.

Comment on Don’t clutter your code with isDebugEnabled by LCB

LCB — Tue, 09 Jun 2009 16:06:30 +0000

Or, you can just set the Log4J config to not log at the debug level, but rather at a higher level. IIRC, you can define your own levels – but I haven’t tried that.

Comment on Don’t clutter your code with isDebugEnabled by Eugene Kuleshov

Eugene Kuleshov — Tue, 09 Jun 2009 15:43:20 +0000

FoX, like I said, in some cases it won’t be ignorable. I am quite certain that isDebugEnabled() call can be inlined by the hotspot compiler, while debug() call will be too large to inline, hence cause the overhead.

Comment on Don’t clutter your code with isDebugEnabled by FoX

FoX — Tue, 09 Jun 2009 13:42:45 +0000

@Eugene: The performance aspect of the log method is ignorable in this case, but the size() method would still be called. I guess making the examples more realistic would be better. Let's say we would like to add some logging for auditing reasons, like the following statement: logger.debug("User '{}' altered entity '{}' on {}.", user, entity, date); The toString() of the objects won't be called in this case and the code will be more readable than using the isDebugEnabled() construction.

Comment on Don’t clutter your code with isDebugEnabled by Caligula

Caligula — Tue, 09 Jun 2009 13:26:10 +0000

But list.size() and user.getName() will still be called: trivial in this case, but if they were expensive you’d *still* have to wrap it in an isDebugEnabled().

Comment on Don’t clutter your code with isDebugEnabled by Eugene Kuleshov

Eugene Kuleshov — Tue, 09 Jun 2009 13:25:17 +0000

On a performance critical path it is still better to write:

if(logger.isDebugEnabled()) {
logger.debug(“The size is ‘{}’, for ‘{}’.”, list.size(), user.getName());
}

because call to the log method is going to be more expensive.

Comment on Don’t clutter your code with isDebugEnabled by FoX

FoX — Tue, 09 Jun 2009 13:04:17 +0000

@Ceki, @Bhima: You are correct, I’ve changed the examples to be more trustworthy.

Comment on Don’t clutter your code with isDebugEnabled by Bhima

Bhima — Tue, 09 Jun 2009 12:48:33 +0000

Regarding the case :
logger.debug(String.format(“The size is ‘%s’, for ‘%s’.”, list.size(), user.getName()));

Doesn’t this suffer from the same problem that normal log4j logging suffers from? The String.format method will be always be executed regardless of what the debug level is.