Комментарии 5
Сначала таблица, понять которую можно только прочтя последующий текст.
Есть сравнение двух библиотек, но итог сравнения не вынесен в таблички.
А самое интересное — особенности подкапотной реализации, приводящей к разнице в скорости, сокрыты где-то в недрах.
Отдельно отмечу про логгирование с кучей параметров — там изрядное время отъедает сборка строки, но не надо её оптимизировать несколькими вызовами логгера, скорее надо самому ускорять сборку строки.
Ещё не рассмотрен такой акспект, как скорость отработки layout-а записей — там указывается формат строчки в файловом логе и можно напихать много чего. Этой фичей многие пользуются, но знают ли её цену?
И ещё, у вас заголовок не соответствует контенту. По заголовку подразумевается, что будет описание того, как ускорить запись в лог, а не сравнение некоторого подмножества функций двух библиотек.
Отдельно отмечу про логгирование с кучей параметров — там изрядное время отъедает сборка строки, но не надо её оптимизировать несколькими вызовами логгера, скорее надо самому ускорять сборку строки.
Ещё не рассмотрен такой акспект, как скорость отработки layout-а записей — там указывается формат строчки в файловом логе и можно напихать много чего. Этой фичей многие пользуются, но знают ли её цену?
Я не смогу цифрами обосновать, а угадывать побаиваюсь. Я постараюсь сделать отдельную статью чуть позже (ну то есть сравнить разные способы заливки больших и малых строк в логгер). Мне только достоверно известно лишь то, что особые нюансы есть с log4j2 (см. тут: https://logging.apache.org/log4j/2.x/manual/async.html)
Есть сравнение двух библиотек, но итог сравнения не вынесен в таблички.
Да, так как я сравнивал не только две библиотеки, а еще и разные схемы работы с ними. Суть этой статьи — как факто того, какой подход быстрее при определенных параметрах.
И ещё, у вас заголовок не соответствует контенту. По заголовку подразумевается, что будет описание того, как ускорить запись в лог, а не сравнение некоторого подмножества функций двух библиотек.
Нельзя понять то, как ускорить лог, без анализа бенчмарков. Нельзя понять правильность выбора библиотеки без их сравнения. И невероятно сложно сравнить полное множество всех функций из всех библиотек.
А самое интересное — особенности подкапотной реализации, приводящей к разнице в скорости, сокрыты где-то в недрах.
Да, возможно. Для меня были интересны прежде всего цифры — а кто именно быстрее. Самые важные моменты (с моей точки зрения), почему NLog быстрее, я вынес (асинхронность, generics, переиспользование массивов).
Я не смогу цифрами обосновать, а угадывать побаиваюсь.
Это очень легко проверить — сравнить обычный вызов с кучей параметров и вызов с одной готовой строкой, отдельно померив время сборки этой строки.
Про название — на медиуме она у вас более правильно названа.
Это очень легко проверить — сравнить обычный вызов с кучей параметров и вызов с одной готовой строкой, отдельно померив время сборки этой строки.
Чуть сложнее, однако с общей идеей я согласен. Если не забуду сделать таки статью, то добавлю следующие вещи:
- Два варианта: включено ли логгирование, или нет. В одном из случаев строка даже не будет создаваться в памяти
- Несколько библиотек (+ SeriLog, т.к. с ним тоже интересно сравнивать, как сказал автор NLog одном коментариев)
- Передавать одно из четырех:
- Заранее сформированную строку
- В виде куче аргументов (т.е. string format + args) за один вызов
Debug - В виде куче аргументов (т.е. string format + args) и в двух-трех вызовах
Debug - В виде
StringBuilder'а, без вызоваToString
Быстрое логгирование