In Log4J, Does Checking Isdebugenabled Before Logging Improve Performance

In log4j, does checking isDebugEnabled before logging improve performance?

In this particular case, Option 1 is better.

The guard statement (checking isDebugEnabled()) is there to prevent potentially expensive computation of the log message when it involves invocation of the toString() methods of various objects and concatenating the results.

In the given example, the log message is a constant string, so letting the logger discard it is just as efficient as checking whether the logger is enabled, and it lowers the complexity of the code because there are fewer branches.

Better yet is to use a more up-to-date logging framework where the log statements take a format specification and a list of arguments to be substituted by the logger—but "lazily," only if the logger is enabled. This is the approach taken by slf4j.

See my answer to a related question for more information, and an example of doing something like this with log4j.

Is Log4j isDebugEnabled() necessary before using logger.debug()?

It's useful when the String your passing to logger.debug(...) takes time to evaluate, in that case you can skip this evaluation if debug is not enabled.

if(logger.isDebugEnabled()) {
    logger.debug("The meaning of life is " + calculateMeaningOfLife());
}

IMO this makes the code a lot less readable so it should only be used when there's a significant performance improvement.

Should we use isDebugEnabled() while logging calculated data with Logback?

Take a look at the example here

Since 2.4, methods have been added to the Logger interface to support lambda expressions. The new methods allow client code to lazily log messages without explicitly checking if the requested log level is enabled. For example, previously one would write:

// pre-Java 8 style optimization: explicitly check the log level
// to make sure the expensiveOperation() method is only called if necessary
 if (logger.isTraceEnabled()) {
     logger.trace("Some long-running operation returned {}", expensiveOperation());
 }

With Java 8, the same effect can be achieved with a lambda expression:

// Java-8 style optimization: no need to explicitly check the log level:
// the lambda expression is not evaluated if the TRACE level is not enabled
logger.trace("Some long-running operation returned {}", () -> expensiveOperation());

Is there a need to do a if(log.isDebugEnabled()) { ... } check?

The statement:

if(log.isDebugEnabled()){

Is used just for performance reasons. It's use is optional since it is called by the log method internally.

But now you ask if this check is made internally, so why should I use it?
It's very simple: if you log something as simple as this:

log.debug("ResultSet rs is retrieved from OracleTypes");

Then you don't need to do any check. If you compose a string to log using the append operator (+) like this:

log.debug("[" + System.getTimeInMillis() + "] ResultSet rs is retrieved from OracleTypes");

In this case you should check if the log is enabled or not, because if it isn't, even if the log is not made, the string composition is. And I must remind you that the use of operator "+" to concatenate strings is very inefficient.

Checking whether there is a logger set to DEBUG in Log4J

If you are having performance issues with Log4j I recommend taking a look at logback.

If you need to stick with log4j you can do one of the following.
The following code will check the logging level of the root logger. This is likely all you need.

Level level = LogManager.getRootLogger().getLevel();
if(level == Level.DEBUG)
    System.out.println("DEBUG");

In the event that you actually do want to check every logger, you can do this.

 for (Enumeration<Logger> en = LogManager.getCurrentLoggers(); en.hasMoreElements();)
   System.out.println(en.nextElement().isDebugEnabled());

For completeness you can change the root logging level with the following.

LogManager.getRootLogger().setLevel(Level.DEBUG);

Log4J: problem with isDebugEnabled() method

The reason seems to be a conflict with a dependency introduced through maven.
I have tested to delete some of these dependencies, and it finally worked.
I do not understand why, but... it works!

Log4J - Test log level useful?

It is not useful for the example that you provided. But it can be useful if you include other data in the log line, for example:

logger.debug("Info: " + someObject.getSomeInformation());

Note that the method getSomeInformation will be called on someObject before logger.debug is called, whether the level is debug or not. Also, a string concatenation will be performed. To avoid the cost of the method call and string concatenation, you can put this in an if like in your question.

---

Related Topics