Comments 25
Используйте if (log.IsDebugEnabled) [...] Обычно отладочных сообщений в коде много и, если их не накрывать таким if-ом, они могут сильно просадить скорость выполнения.
Это же на уровне логгера должно делаться вроде как (и Serilog это прекрасно делает, кстати). Если это надо делать в прикладном коде, с логированием что-то фундаментально не так.
Всё что может сделать serilog это не делать свою обработку, но стоимость простого вызова метода никто не отменял
Конкретно взятый серилог эту проблему решает так: https://github.com/serilog/serilog/blob/v2.10.0/src/Serilog/Core/Logger.cs#L229
Если инфраструктура фотона так не делает, значит одно из двух: или эта потеря производительности на самом деле не важна (как в Microsoft.Extensions.Logging; еще точнее, там это просто сделано другим образом), или они не подумали, а должны были.
В своё время, когда я столкнулся с этим прирост производительности был заметен даже на глаз. Но решение было использовать выше указанную проверку.
но тем не менее в общем случае я бы всё равно использовал предварительную проверку.
Необходимость постоянно писать избыточный код плохо говорит о фреймворке. Посмотрите, как сделано в M.E.L.
Нет, конечно. Зачем?
Так я и string.Format("{0}...") не использую, у меня структурное логгирование.
Где на практики плюсы. Я бегло посомтрел в файл, там в общем-то тоже самое, как если бы я log4net пользовался
ну т.е. вы только serilog используете, так?
Нет, конечно. Еще я использую Microsoft.Extensions.Logging.
Где на практики плюсы.
На практике плюсы там, где вы пишете в структурированное хранилище, начиная с JSON-файлов, и заканчивая AWS CloudWatch, Elasticsearch и Seq. А потом при анализе логов просто говорите "ага, хочу все логи от такого-то запроса для такого-то компонента для такого-то токена".
Я бегло посомтрел в файл, там в общем-то тоже самое, как если бы я log4net пользовался
… в обычный текстовый файл, наверное? Нет, там вы плюсов не найдете.
Интересно почему делегаты не завезли как в NLog
_logger.Info(() => string.Format("msg", myParams));
Потому что еще не факт, что создание (и потенциальный вызов) делегата дешевле, чем создание массива.
Базовый интерфейс логгера был сделан на основе log4net. И его в общем-то не трогали, потому что свою работу он делал.
ну и согласен с lair, что эффективность такого подхода сомнительна
Допустим у вас есть какой-то адаптер созданный за час. И вы пользуетесь serilog. Благодаря адаптеру, в любой момент вы можете подсунуть другой. Но это только в начале. Потому что потом выяснится, что, чтобы использовать мощь serilog, строки сообщений были сформированы под структурное логгирование. Потом вам где-то пришлось использовать эниричеры, чтобы получить дополнительную инфу об источнике сообщений. Всё это было сделано не по прихоти разработчиков, а исходя из реальных потребностей.
И вот уже переехать на другой логгер будет сложно. Либо убиваться и расширять адаптер, но очевидно что задача не очень благодарная.
Знаете, у меня вот под рукой система, в которой внутри серилог, а снаружи абстракция, которая про серилог не знает. И оно вполне себе нормально работает.
А с появлением Microsoft.Extensions.Logging это и вовсе пустой вопрос, потому что он и представляет собой нужную абстракцию.
попробовали таки применить serilog. При впечатляющей производительности оказалось, что мы очень ограничены по конфигурации, т.е. нельзя во так вот просто во время работы приложения обновить файл конфигурации, добавив туда новых логгеров со своими собственными аппендерами и уровнем логгирования.
Для нас это критично
Если я не прав, то буду рад встать на путь истинный
Photon это не только log4net