Комментарии 15
Присоединяюсь, очень интересно что именно имеется ввиду под "Zero Allocation JSON Serializer" у Utf8Json.
Интересная библиотека кстати, дотошность оптимизаций впечатляет!
Jil вряд ли заброшена, на нее по прежнему есть ссылка на страничке производительности StackOverflow.
Как не нужно? что он по умолчанию в .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% оптимизации
Битва C# JSON сериализаторов для .NET Core 3