Сколько на самом деле стоит LOG_INFO(): benchmark библиотек логирования C++

[schulzr]

спасибо, а почему вы для бенчмаркинга выбрали именно эти библиотеки? они по-вашей оценке наиболее развитые?

[emishkurov]

spdlog, пожалуй, действительно самая известная библиотека. Что касается quill и easylogging++, их предложил ChatGPT в ответ на мой вопрос о том, какие ещё решения наиболее распространены в мире логирования.

logme — это, собственно, моя библиотека. Изначально я ставил себе задачу сравнить реальную производительность различных библиотек. Поскольку результаты получились достаточно интересными, решил ими поделиться.

[schulzr]

Хотелось бы уточнить. Эти библиотеки mt-safe?

Насколько дорого гарантировать потоко-безопасность?

[emishkurov]

В бенчмарке большинство библиотек уже работали в MT-safe режиме (включен в режиме “из коробки”), тогда как easylogging++ согласно документации — нет. Поэтому сравнение не занижает её результат — скорее наоборот.

[empelde]

Лет 10 назад доводилось реализовывать логирование для высоко нагруженных систем.
Идея была − минимум времени/работы в рабочем потоке. На языке вашего теста все бы свелось к проверке уровня логирования. Если null, то на этом бы расходы и закончились. В противном случае динамические параметры для форматирования, А также временной штамп, ID потока, И уникальный ID сообщения (раздается независимо от потока), закидывались в потокобезопасную очередь. А потом уже другой поток, ответственный за логирование это все разгребал, используя вспомогательные потоки.

Мне кажется у Вас в статье ошибочное допущение, что разработчики высоконагруженных приложений вот так вот возьмут и будут логировать "тяп−ляп из коробки". Это верно только частично - eсли производительность приложения их устраивает. В портивном случае, они задумаются, как оптимизировать логирование и ваш бенчмарк потеряет актуальность.

[emishkurov]

Спасибо, вы описываете абсолютно здравый и, по сути, канонический подход для high-load систем — минимальная работа в рабочем потоке и перенос всего остального в асинхронную обработку.

И да, вы правы: в реальных проектах логирование почти никогда не используется «из коробки». Его настраивают под конкретные требования — формат, состав полей (timestamp, thread id и т.д.), синхронный/асинхронный режим, буферизацию, фильтры и прочее. В этом смысле итоговая производительность определяется не только библиотекой, но и архитектурой логирования в целом.

В бенчмарке же была немного другая цель. Мы сознательно упростили сценарий (логирование только сообщения без дополнительных полей), чтобы привести разные библиотеки к максимально сопоставимым условиям. Это не попытка смоделировать production, а скорее попытка получить «базовую стоимость» вызова логирования при прочих равных.

Если сразу сравнивать «как в жизни», то получится сравнение конкретных конфигураций (и даже конкретных подходов к логированию), а не библиотек — и такой результат будет сильно зависеть от выбранных настроек.

Поэтому я бы рассматривал этот тест скорее как отправную точку: он не отменяет необходимости тюнинга под конкретный проект, но позволяет получить общее представление о накладных расходах библиотек в более-менее нейтральных условиях.

А дальше — полностью согласен — в реальной high-load системе без дополнительной настройки логирования обычно никуда