Project

General

Profile

Actions

Bug #4958

closed

[efsm][simulator] Избыточное использование метода isLoggable

Added by Alexander Kamkin over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Start date:
05/23/2014
Due date:
% Done:

0%

Estimated time:
Detected in build:
svn
Platform:
Published in build:

Description

Вызов метода isLoggable является избыточным - уровни автоматически проверяются логгером.
Предлагаю убрать.

Actions #1

Updated by Igor Melnichenko over 10 years ago

Он вызывается, чтобы не выполнялась лишняя конкатенеция строк (это может сильно ударить по производительности). Предлагаю оставить.

Actions #2

Updated by Alexander Kamkin over 10 years ago

Какая конкатенация?
Как сильно снизится производительность?

Actions #3

Updated by Igor Melnichenko over 10 years ago

Например:
if (this.logger.isLoggable(LogLevel.INFO)) {
this.logger.log(LogLevel.INFO, this.logEntryHeader
+ ": starting to process the events: " + events);
}

Если убрать проверку isLoggable, то вне зависимости от того, какой уровень сейчас установлен, перед вызовом this.logger.log будет собрана строка, равная this.logEntryHeader + ": starting to process the events: " + String.valueOf(events). Насколько я знаю, в текущей реализации JVM это будет преобразовано в создание одного StringBuilder'а, трёх String'ов, их последовательное добавление в StringBuilder, вызов String.valueOf и вызов метода toString() у StringBuilder'а.
Проверка isLoggable в случае, если логирование включено не для всех уровней, позволяет сэкономить память и процессорное время. Насколько сильно - это уже надо на конкретных примерах проверять.

Actions #4

Updated by Alexander Kamkin over 10 years ago

В среднем в логер передаются две строки (заголовок и данных), их конкатенация хоть и снижает производительность, но не критично (тем более в нашем случае, где некоторые методы, например, реконструкция EFSM по CFG, имеют высокую вычислительную сложность - относительные затраты на логирование небольшие). Без проверки код получается компактнее, и, что самое главное, не нужно два раза указывать уровень логирования (это источник ошибок).

На этапе разработки альфа-версии вопросы производительности (если это не специальное приложение) отодвигаются на задний план. Наглядность кода и удобство его правки приоритетнее.

В бета-версии мы можем вернуться у этому вопросу и произвести замеры производительности.

Actions #5

Updated by Igor Melnichenko over 10 years ago

  • Status changed from New to Resolved

Готово.

Actions #6

Updated by Alexander Kamkin over 10 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF