В log4j проверка производительности isDebugEnabled перед регистрацией улучшает производительность?

Question

Я использую Log4J в моем приложении для ведения журнала. Ранее я использовал вызов отладки, как:

Вариант 1:

logger.debug("some debug text");

но некоторые ссылки предполагают, что лучше сначала проверить isDebugEnabled(), например:

Вариант 2:

boolean debugEnabled = logger.isDebugEnabled();
if (debugEnabled) {
    logger.debug("some debug text");
}

Итак, мой вопрос: " Улучшает ли вариант 2 производительность? ".

Потому что в любом случае каркас Log4J имеет ту же проверку для debugEnabled. Для варианта 2 может быть полезно, если мы используем несколько операторов отладки в одном методе или классе, где каркасу не нужно вызывать метод isDebugEnabled() несколько раз (при каждом вызове); в этом случае он вызывает метод isDebugEnabled() только один раз, а если Log4J настроен на уровень отладки, то фактически он вызывает метод isDebugEnabled() дважды:

1. В случае присвоения значения переменной debugEnabled и
2. На самом деле вызывается методом logger.debug ().

Я не думаю, что если мы напишем несколько операторов logger.debug() в методе или классе и вызовем метод debug() в соответствии с вариантом 1, тогда это издержки для инфраструктуры Log4J по сравнению с вариантом 2. Поскольку isDebugEnabled() является очень маленький метод (с точки зрения кода), он может быть хорошим кандидатом для встраивания.

Answer 1

Это повышает скорость, потому что обычно объединять строки в тексте отладки, что дорого, например:

boolean debugEnabled = logger.isDebugEnabled();
if (debugEnabled) {
    logger.debug("some debug text" + someState);
}

Answer 2

Log4j2 позволяет вам форматировать параметры в шаблон сообщения, аналогично String.format(), что избавляет от необходимости делать isDebugEnabled().

Logger log = LogManager.getFormatterLogger(getClass());
log.debug("Some message [myField=%s]", myField);

Пример простого log4j2.properties:

filter.threshold.type = ThresholdFilter
filter.threshold.level = debug
appender.console.type = Console
appender.console.name = STDOUT
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = %d %-5p: %c - %m%n
appender.console.filter.threshold.type = ThresholdFilter
appender.console.filter.threshold.level = debug
rootLogger.level = info
rootLogger.appenderRef.stdout.ref = STDOUT

Answer 3

Начиная с 2.x, в Apache Log4j встроена эта проверка, поэтому isDebugEnabled() больше не требуется. Просто сделайте debug(), и сообщения будут подавлены, если не включены.

Answer 4

Я бы порекомендовал использовать Вариант 2 как де-факто для большинства, так как это не супер дорого.

Случай 1: log.debug ("одна строка")

Вариант 2: log.debug («одна строка» + «две строки» + object.toString + object2.toString)

В то время, когда любой из них вызывается, строка параметра в log.debug (будь то CASE 1 или Case2) должна быть оценена. Вот что все подразумевают под «дорогой». Если перед вами есть условие isDebugEnabled (), их не нужно оценивать, где сохраняется производительность.

Answer 5

Если вы используете вариант 2, вы выполняете булеву проверку, которая выполняется быстро. В первом варианте вы выполняете вызов метода (помещая вещи в стек), а затем выполняете логическую проверку, которая все еще быстра. Проблема, которую я вижу, это последовательность. Если некоторые из ваших операторов отладки и информации обернуты, а некоторые нет, это не соответствует стилю кода. Плюс кто-то позже мог бы изменить оператор отладки, чтобы включить строки сцепления, что все еще довольно быстро. Я обнаружил, что когда мы завершили отладку и информацию в большом приложении и профилировали его, мы сэкономили пару процентов производительности. Не много, но достаточно, чтобы оно того стоило. Теперь у меня есть пара настроек макросов в IntelliJ для автоматического создания завернутых отладочных и информационных операторов для меня.