Как стать автором
Обновить

Комментарии 15

В бенчмарках не хватает информации об аллокациях. Эта информация легко объяснила бы последний бенчмарк

Присоединяюсь, очень интересно что именно имеется ввиду под "Zero Allocation JSON Serializer" у Utf8Json.
Интересная библиотека кстати, дотошность оптимизаций впечатляет!

Только жаль, что они заброшены. У Utf8Json последний коммит — 9 июня 2018, а у Jil — 24 декабря 2019.
" Для System.Text.Json вообще ничего не нужно делать."
Как не нужно? что он по умолчанию в .net core 3?
Да
Да

А для чего вам потребовался клиент? Для тестирования на нагрузку есть jmeter. Который умеет ещё и графики строить.
Так же данный тест не отображает функциональность этих библиотек.
Тот же Newtonsoft умеет в readonly property, а мелософтовский точно нет.

Сколько сериализаторов было и сколько коллег там успешно полегло…
Каждый раз сериализаторы на тестах своих создателей показывают как они хороши по сравнению со стандартными. И в каждом случае они то точно лучше конкурентов. Но только стоит начать работать с ними, как будет видно, что всегда выползают недоработки связанные с особенностями оптимизаций, где объект «до» и объект «после» совсем не идентичны. А ещё есть не поддерживаемые типы, проблемы версий скриптов, проблемы с изменением сборок. Все они требуют особого написания кода и структурирования данных, которое не совпадает с нормальным или даже «ручной» сериализации сложных классов.

К чему нужны эти тесты, если всё равно не получится сериализовать боевой код? Без сравнительного анализа возможностей просто бессмысленно.
Автор использовал простейшие классы, без перекрёстных ссылок, сложных типов, ну и без генерации строк(а это важно, т.к. все объекты в тестах вероятно имели одинаковые ссылки, а обычно бывает как раз наоборот).

PS: для каждого случая можно написать сериализатор, который будет быстрее более универсального на каком-то заранее определённом наборе данных.
В целом согласен, но не понял что имелось ввиду под одинаковыми ссылками?
Все строки одинаковые, да ещё заданы «по умолчанию», должно происходить интернирование.

Я проводил подобное исследование для своего проекта, в итоге мы перешли с newtonsoft на system text.json, а остальное не стали использовать.
Дело в том, что очень значительный выигрыш производительности получается от строгости парсера. Что utf8json, что system text по умолчанию парсят только полностью валидный json да ещё case sensitive. Это конечно быстрее, но в глобальном апи сервисе, где люди часто для тестирования отправляют запросы руками через postman, а потом эти же строки вставляют в свой код, уже нельзя подходить с такой строгостью. Мы поняли, что мы сломаем колоссальное количество клиентов, если включим case sensitive и полную валидацию (например двойные кавычки, а не одинарные) и тп. Newtonsoft всё пропускает и куча клиентов, к сожалению этим уже пользуются. Так что мы перешли на system text, с настройками максимально близкими к newtonsoft и пока живём так. Надо ещё учитывать, что хотя utf8json правда парсит в 4 раза быстрее, общая цена парсинга в нашем запросе около 5%, то есть мы не можем так уж много выиграть даже от 100% оптимизации

В system.text.json достаточен «беден» на функционал, если нужны кастомизация парсера в отличии от newtonsoft. Да и разрыв с newtonsoft по производительности не очень велик.
Прекрасная статья! Спасибо автору!
Сразу прослеживается неопытность подхода: 1. Для оценки производительности необходимо использовать специализированные бенчмарки и учитывать алокации помимо времени выполнения2. Для точной оценки необходимо сравнивать производительность при использовании IBufferWriter, но старые сериализаторы его не поддерживают
Зарегистрируйтесь на Хабре, чтобы оставить комментарий