У проекта silentjson вышла версия 2.0.0, и цифры у релиза такие, что парсинг JSON в Go впервые выглядит не как спор библиотек, а как спор с пропускной способностью памяти. По данным Habr / Новости, на AMD Ryzen 9 7950X3D авторы получили до 24 670 МБ/с в режиме AVX2 при обработке 100 000 объектов. Для Go-разработчиков это важный сигнал: в узких местах backend-сервисов и IPC-цепочек парсинг JSON в Go снова стал темой не про «достаточно быстро», а про пределы железа.
Речь идет о silentjson — JSON-парсере для Go без кодогенерации и без аллокаций. В версии 2.0.0 команда сосредоточилась не на косметических улучшениях, а на двух конкретных задачах: поднять эффективность на системах без AVX2 и дожать сценарии, связанные с hft-ipc. Формулировка у авторов почти провокационная: программные накладные расходы они, по сути, вычистили настолько, что дальше скорость ограничивают уже не алгоритмы как таковые, а CPU и память. В мире Go, где многие годы эталоном по умолчанию оставался стандартный encoding/json, это звучит как вызов всей привычной иерархии инструментов.
Самое любопытное в релизе — не только пиковые числа, но и то, как они распределяются по режимам. В опубликованном фрагменте бенчмарков стандартный encoding/json показал 110 МБ/с, Sonic с JIT — 644 МБ/с, SilentJSON в scalar-режиме — 810 МБ/с, а SilentJSON с AVX2 — 24 670 МБ/с. Даже если смотреть без восторга и с нормальной инженерной подозрительностью, разница заметна. Особенно важен scalar fallback: авторы отдельно подчеркивают, что серьезно оптимизировали путь без AVX2, то есть не оставили «обычный» режим в роли бедного родственника. Это хороший знак для команд, которые живут не только на свежих серверных CPU, но и на более консервативной инфраструктуре, виртуалках с ограниченными инструкциями или mixed-environment, где набор SIMD-возможностей не гарантирован.
При этом разработчики не пытаются продать читателю сказку про бесплатную бесконечную производительность. В заметке прямо сказано, что при симуляции тяжелого сценария под внешней стресс-нагрузкой скорость парсинга просела на 60%. Для маркетингового текста это почти неприличная честность, и именно поэтому ей хочется верить. Важна, впрочем, вторая часть этой фразы: даже после такой просадки silentjson, по словам авторов, остается далеко впереди конкурентов. Это уже интереснее для практики, чем сам рекордный пик на чистом стенде. В реальных системах никто не живет в лаборатории: рядом всегда крутятся другие процессы, шуршит сеть, шумит память, а CPU занят не только вашим красивым JSON.
Контекст у этой истории тоже вполне понятный. Ускорение JSON-парсинга давно стало отдельной микроиндустрией: кто-то идет через кодогенерацию, кто-то через JIT, кто-то через SIMD и ручную работу с памятью. В Go этот разговор особенно нервный, потому что язык часто выбирают для инфраструктурных сервисов, API-шлюзов, стриминговых компонентов и внутренних систем с очень предсказуемыми, но массовыми сериализационными нагрузками. Когда в таких местах экономится даже не миллисекунда, а заметная доля CPU-времени на каждом запросе или сообщении, разница быстро превращается в вполне материальные деньги на масштабе. И здесь silentjson играет на понятной боли: без кодогенерации, без аллокаций, с акцентом на throughput, а теперь еще и с явной ставкой на сценарии, где задержка и пропускная способность важнее универсальности.
Отдельная деталь — упоминание hft-ipc с коротким комментарием «кто знает, тот поймет». Для массовой аудитории это почти мем, но для инженеров из low-latency-среды намек предельно прозрачный. Если библиотека всерьез тестируется и оптимизируется под высокочастотные межпроцессные взаимодействия, значит, авторы целятся не в абстрактные синтетические победы в GitHub-табличке, а в режимы, где каждая лишняя аллокация и каждый промах по кешу имеют цену. Конечно, из короткой заметки нельзя делать вывод, что silentjson завтра станет стандартом де-факто в HFT или replace-all решением для любого продакшена. Но сам вектор понятен: проект пытается занять нишу там, где Go обычно критикуют за избыточную «общность» по сравнению с системными языками.
Для разработчиков и техлидов из этого релиза следует несколько практических выводов. Первый: если у вас сервис утыкается в сериализацию и десериализацию, эпоха «ну JSON в Go и так достаточно быстрый» закончилась не везде, но уже во многих местах. Второй: сравнивать библиотеки теперь нужно не только по API и удобству интеграции, но и по типу целевой машины. Разница между scalar-режимом и AVX2 здесь не косметическая, а почти философская. Третий: красивые бенчмарки все еще требуют своей дозы скепсиса. Авторы сами предлагают проверять результаты и публиковать собственные замеры в комментариях, а обновление доступно через go get github.com/GenshIv/silentjson@v2.0.0. Это правильная позиция: в вопросах производительности доверять стоит не баннеру, а своему профилировщику, своей нагрузке и своему набору данных.
Для бизнеса и продуктовых команд новость не в том, что появилась еще одна «самая быстрая» библиотека. Таких заявлений рынок видел достаточно. Новость в другом: парсинг JSON в Go добрался до этапа, где в отдельных сценариях оптимизация упирается в физические ограничения платформы, а не в очевидные промахи реализации. Если это подтверждается на независимых тестах, спор о производительности постепенно смещается с уровня «какой пакет подключить» на уровень архитектуры системы, профиля нагрузки и класса железа. А это уже более зрелый разговор: не про магическую серебряную пулю, а про то, где у вашей инфраструктуры заканчивается софт и начинается реальная цена памяти, кешей и инструкций процессора.