Производительность: почему zap быстрый

zap производительность складывается из трёх источников. Первый — типизированные поля: конструкторы zap.String и zap.Int64 возвращают zapcore.Field — структуру с кодом типа, и энкодер делает switch по коду, записывая значение напрямую, без reflect. Второй — переиспользование: записи CheckedEntry лежат в sync.Pool, буферы под JSON тоже, и сборщик мусора видит константный объём работы. Третий — проверка уровня до сборки: выключенный уровень — это сравнение int8 и возврат, самая дешёвая ветка в системе. Всё вместе README zap называет zero-allocation JSON encoding: сама кодировка в буфер аллокаций не делает. Заметьте, чего в списке нет: записи на диск и fsync — скорость кодировки не отменяет цену вывода, о нём отдельный разговор ниже.

Field — маленькая структура из четырёх полей: ключ, код типа, строка и интерфейс. Конструктор zap.String кладёт значение в строковый слот, zap.Int64 — в целочисленный, и энкодер JSON делает switch по коду: строку экранирует, число пишет напрямую. Рефлексии в этом пути нет вообще — и это главный ответ на вопрос «чем zap быстрый». Интерфейсное поле достаётся сложным случаям: zap.Object, zap.Any и ошибки. Отсюда практическое правило: в горячем коде поле — конструктор с конкретным типом, а zap.Any — инструмент для краёв, где тип неизвестен заранее. Компилятор частично страхует: zap.String("n", 42) не скомпилируется. А вот zap.Any("n", 42) пройдёт тихо — и скроет от вас, что поле пойдёт через общую ветку.

SugaredLogger оборачивает Logger: Infow принимает пары ключ-значение через interface{}, и на каждой записи значения проходят sweetenFields — type switch, а для незнакомых типов reflect. Это не «в десять раз медленнее» на фоне вывода в файл: надбавка — наносекунды на поле, плюс возможные аллокации на упаковке. Дороже другое, человеческое: пары ключ-значение не типобезопасны, перепутать местами ключ и значение легко, и компилятор молчит. Моё рабочее разделение, за которое меня ругали: сахар — на краях приложения, инициализация, CLI-команды, разовая диагностика; типизированный API — в обработчиках запросов и любых циклах. Если у вас сотни записей в минуту, выбирайте то, что читается командой: производительность здесь не аргумент.

logger.Info внутри zap устроен так: проверка Enabled, сборка CheckedEntry из sync.Pool, добавление полей, запись, возврат в пул. Для выключенного уровня всё заканчивается проверкой — но поля вызова уже собраны на месте вызова: varargs-слайс и конструкторы полей стоят, даже когда запись не состоится. Для самых горячих мест zap предлагает Check: ce := logger.Check(zapcore.InfoLevel, "event") — и только если ce не nil, вызывать ce.Write с полями. Здесь поля собираются после проверки уровня: выключенный уровень не тратит ни байта. Приём оправдан, когда вероятность записи мала, а построение полей дорого — сериализация больших объектов, форматирование длинных строк.

Данные из репозитория zap задают порядок величин: статическая строка — десятки наносекунд на запись, запись с десятком полей — сотни, и это без учёта вывода. SugaredLogger дороже типизированного API, стандартная log — выше zap на порядок на тех же полях. Переносить цифры на своё железо нельзя: результат зависит от числа и типов полей, энкодера, размера сообщений и особенно WriteSyncer — в бенчмарках zap вывод подменён на ioutil.Discard, и реальная запись в файл будет другой. Рабочая методика одна: go test -bench . -benchmem на своём коде и своём выводе на локальном Go, и смотреть ns/op и allocs/op отдельно — аллокации предсказывают поведение под GC лучше, чем наносекунды.

WriteSyncer по умолчанию обёрнут в zapcore.Lock: мьютекс на каждую запись. Запись атомарна — две горутины не перемешают JSON в одну строку, но при большом числе пишущих горутин мьютекс становится точкой спора: все ждут одного писателя. На практике это видно на многоядерных машинах с большим потоком логов: contention появляется в профиле как ожидание на мьютексе. Лекарства три — sampling из урока про сэмплирование, уменьшение объёма и буферизованный writer, который сглаживает частоту системных вызовов, но сам мьютекс не отменяет. Атомарность держится на буфере: энкодер собирает запись целиком и отдаёт WriteSyncer одним вызовом Write — поэтому в логе нет половинных строк, и строка неделима.

Атомарный уровень из урока про динамические уровни читается на каждом Check — смена порога видна со следующего же вызова, перезапуск не нужен. Две границы момента. Вызовы, уже прошедшие Check и собирающие поля, запись допишут: половины записи не бывает, буфер получает её целиком или не получает ничего. И смена порога не размагничивает историю: записи прежнего уровня уже в хранилище, дашборды не пересчитываются. На практике переключение Info на Debug на горячем сервисе мгновенно умножает объём: цена не в Check, который стоит сравнение, а в потоке записей под новым порогом. Перед сменой на проде — убедиться, что хранилище и система сбора переживут кратный рост.

В ревью я видел споры о длине ключей и порядке полей — на фоне вывода разница неразличима, и я не трачу на это время. Что действительно двигает цифры: sampling, который превращает тысячу повторов в пару записей, динамические уровни, отключающие Debug на проде без перезапуска, и разумный минимум полей. Отдельно про чистку полей: убрать поля, которыми никто не пользуется, — не микрооптимизация, а гигиена, каждое поле — байты в хранилище и время индексации. Но начинать стоит с измерения, а не с чистки: если логи не видны в профиле, ускорять нечего, и время лучше потратить на вывод и уровни. Быстрый логгер go — это в первую очередь дисциплина объёма, а не тонкие настройки.

Механика ядра — интерфейс Core из пяти методов, через который проходят и Check, и Write — разобрана в уроке про zapcore; про обрезание потока в цифрах — урок про сэмплирование. Если типизированный API кажется многословным для краёв кода, посмотрите мост logr и zapr — тот же zap под другим интерфейсом. Карта курса — на странице курса zap.