Регистратор Sorrounding с Выражением if для предотвращения избыточной Строковой конструкции
Я получил рекомендацию использовать этот синтаксис при входе в систему Java:
if (logger.isLoggable(Log.FINE))
{
logger.fine("bla"+" bla"+" bla");
}
Причина этого состоит в том, чтобы избежать, чтобы избыточная конструкция строки параметров упаковала регистрирующийся уровень, ниже, чем "ПРЕКРАСНЫЙ". (в примере выше - 5 избыточных строковых объектов. (" bla "X3, "bla bla" и "bla bla bla").
Я хотел бы услышать то, что другие делают об этом или если Вы думаете, что это необходимо вообще.
Спасибо!!
4 ответа
Некоторые новые рамки ведения журнала позволяют указывать аргументы в качестве параметров, и не оценивают их, если нет журнала.
Пример, который я нашел, это вход в логин, преемник для log4j. Вот информация: http://www.infoq.com/news/2007/08/logback
Это дает вам лучшее из обоих миров, так сказать. Элегантный синтаксис, но хорошая производительность.
ПРИМЕР КОДА LOG4J:
if( logger.isDebugEnabled() ) {
logger.debug( "User with account " +
user.getAccount() + " failed authentication; " +
"supplied crypted password " + user.crypt(password) +
" does not match." );
}
Эквивалентный код обратного обратного плана:
logger.debug( "User with account {} failed authentication; " +
"supplied crypted password {} does not match.",
user.getAccount(), user.crypt(password) );
Это дефицит затраты на сборку, до тех пор, пока логин не будет установлен, будет ли это сообщение будет просмотрено. Он не отсчитывает стоимость извлечения дорогих параметров, таких как крепкование пароля в приведенном выше примере.
Это улучшение (хорошее), но его можно немного улучшить.
Установите окончательные флаги для каждого уровня протоколирования (FINE и т.д.) в глобальном объекте, используемом в качестве конфигуратора, затем используйте StringBuffer для построения отладочного вывода -- вы даже можете форматировать числа в поток одновременно.
public class MyAppConfig {
public final boolean FINE=true;
// ... other fields
}
public class MyApp {
void someFunction() {
...
int imagesProcessed;
imagesProcessed = processImages();
if (MyAppConfig.FINE) logger.fine(new StringBuffer(35).
append("Count of images processed: ").append(imagesProcessed).toString());
...
}
}
Здесь буфер строк настраивается с 'начальным объемом' в 35 символов. Если вы знаете, сколько символов будет сгенерировано, вы можете дать подсказки StringBuffer.
Строковые объекты неизменяются, и повторяющееся конкатенацию, следовательно, является дорогой операцией. Требуется повторное распределение памяти, создание объектов и итерации. Учитывая, что некоторые регистрирующие вызовы на более тонких уровнях журнала могут быть вызваны тысячами или миллионами времени в минуту, это может быть значительный прирост производительности, когда вы иллюстрируете. Хотя, для небольшого приложения, это может не стоить дополнительных усилий.
Как сбоку Примечание. Вы можете сохранить еще более производительность, где это действительно важно, используя константу, такую как это:
public static final boolean DEBUG = false;
, если вы теперь оберните код ведения журнала в IF-блоке, например, в этом, JVM будет Сможете полностью оптимизировать вызовы отладки при работе в режиме продукта. Это так близко, как вы добираетесь до C #iFDEF.
if (Globals.DEBUG) {
// Logging call
}
Абсолютно необходимо для регистрации типа отладки. Это что-то вроде 10x быстрее проверить уровень журнала, чем создать строку и выбросить ее.