Насколько медленны C, F, L, l и M PatternLayout (log4j)? - PullRequest
12 голосов
/ 27 января 2011

Общеизвестно, что C, F, L, l и M PatternLayout являются медленными :

ПРЕДУПРЕЖДЕНИЕ Генерация информации о местоположении вызывающего абонента является чрезвычайно медленной, и ее следует избегать, если только скорость выполнения не является проблемой.

Кроме того, в этой книге упоминается, что некоторые приложения могут набрать 10% скорости только за счет изменения формата ведения журнала.

Но вопрос в том, насколько медленны эти символы преобразования?

Ответы [ 3 ]

10 голосов
/ 04 февраля 2011

Я измерил локально на моем компьютере, используя FileAppender.Я хорошо разогрел тест, измерил много выполнений и усреднил (относительно непротиворечивые) результаты.Цикл содержал execs++;log.info("t"); Точные числа не имеют значения (потому что они зависят от моего компьютера), но пропорции имеют значение.Я использовал log4j-1.2.16.jar на Java 1.6.0_10 (клиентская виртуальная машина).

Оказывается, что всякий раз, когда какой-либо из C, F, L, l or M появлялся в шаблоне, ведение журнала было как минимум в 5 раз медленнее.1005 *

enter image description here

6 голосов
/ 05 февраля 2011

Основная причина того, что они помечены как медленные, заключается в том, что информация, которую они представляют, извлекается путем генерирования исключения и анализа трассировки стека исключения.

Когда был разработан PatternLayout, генерация трассировки стекаочень дорогой процесс, так что это было честное предупреждение.Достижения в технологии JVM улучшились, поэтому процесс уже не такой дорогой.Несмотря на то, что сегодня существуют более быстрые методы получения необходимой информации, они, насколько мне известно, не используются из-за внимания к обратной совместимости с более ранними версиями Java.

Другими словами, это не так плохокак раньше.

2 голосов
/ 27 января 2011

Предполагая, что вы не только академически заинтересованы в ответе, но и беспокоитесь о стоимости регистрации в реальном приложении:

Я использовал их все в рабочих приложениях, и они никогда не создавали проблем, в первую очередь потому, что ведение журнала является относительно редким явлением. Конечно, все эти приложения были привязаны к вводу / выводу (не к диску / разделу, на котором велось ведение журналов), и на машинах было достаточно свободных циклов ЦП (но это были только машины PIII-1133), но это верно для подавляющего большинства из (веб) приложений. Я бы просто использовал их до тех пор, пока профилирование не покажет, что логирование является узким местом, и не беспокоюсь об этом.

...