Сравнение производительности JSON-сериализаторов для .NET

[atd]

Спасибо! Ещё можно вот эту штуку посмотреть jayrock.berlios.de/

[skyboy]

Из этого всего пользовался только Newtonsoft.Json, про некоторые описанные в статье даже не слышал. Есть еще библиотека FastJson www.codeproject.com/KB/IP/fastJSON.aspx, которая работает немного быстрее Newtonsoft, судя по графикам и моим тестам. А вообще после проведения тестов, написали свою библиотеку для сериализации/дессериализации Json.

[DarkGenius]

Это в каких таких задачах не хватает производительности сериализатора от NewtonSoft?

[StanEgo]

>> Сложно придумать способ получающий строку в формате JSON быстрее.

Учитывая иммутабельность строк, использовать конкатенацию в качестве эталона скорости — очень странное решение. Для таких целей придуман StringBuilder.

[XuMiX]

Я просто оставлю это здесь
www.codeproject.com/KB/cs/StringBuilder_vs_String.aspx

[StanEgo]

Сложно серьезно рассматривать тест, в котором не используется главная возможность StringBuilder — аллокация памяти по строковой буффер. Без нее он, естественно, ведет себя точно также как иммутабельные строки.

[XuMiX]

Пруфтест?

[StanEgo]

Пруфтест — хотя бы статья на которую вы же и ссылаетесь, просто читать ее надо внимательней и применять к тому кейсу, который обсуждается, а не абстрактно. На графике прекрасно видно, как с ростом буфера ведет себя билдер, а как остальные методы. Билдер тормозит, поскольку по дефолту он поднимает capacity на длине 16, 32, 64, а потом начинает разгоняться, поскольку все реже и реже нуждается в реаллокациях. Строковые методы напротив начинают тормозить, поскольку с ростом строки ее все тяжелее каждый раз копировать. Просто автор мало того, что не инициализировал билдер как следует, так еще и остановился на конкатенации только 10 строк. Я думаю не надо доказывать, что это не кейс JSON-сериализации.

[jakobz]

А лучше сразу писать в TextWriter.

[StanEgo]

Категорически согласен. Тем более, что бэкендом к нему может быть и StringBuilder через StringWriter.

[stoune]

Почему тестировали на .NET 3.5? Было бы интересно расмотреть поведение там.

[AlexanderG]

Эх, еще бы сравнить скорость сериализации JSON и XML…

[kekekeks]

Автор вот этой штуки утверждает, что она по скорости уделывает всё остальное. Сравните в том же окружении, если не трудно.

[kekekeks]

И такой вопрос, когда на Mono тестировали, были ли включены оптимизации (mono -O=all yourfile.exe)? Так же хотелось бы узнать, учитывалось ли время на «прогрев» среды?

[AlexanderG]

Это не Ява, прогревать тут нечего. Один раз, при запуске, в первой итерации теста бинарник в репозиторий попал, и все.

[kekekeks]

Про emit кода в рантайме, чтобы не ломиться каждый раз через рефлекшн вы слышали? Некоторые библиотеки его активно эксплуатируют для оптимизации. В моно так вообще по умолчанию используется «ленивый» JIT, если ему не сказать --compileall. Так что первый вызов может быть в разы медленее, чем последующие.

[kekekeks]

Тьфу, не так прочитал. В общем, изначально имелось ввиду, сравнивался ли «холодный» вызов или последующие.

[kekekeks]

Учитывая «Тест №1. 10 000 раз выполнялась инициализация сериализатора и сериализация одного и того же объекта» очень похоже на то, что сравнивось ещё и время вызова на холодную.

[petuhov_k]

Компилировал и запускал в Monodevelop и VisualStudio с теми настройками, которые там есть «по умолчанию».
Чтобы исключить время «прогрева», я перед тестом 1 и 2, каждый сериализатор прогонял по 1-му разу.

[kekekeks]

MonoDevelop запускает сборки с мягко говоря не вполне оптимальными настройками, не говоря уже о том, что в большинстве дистрибутивов линукса у Mono отсутствует LLVM-бакэнд.

[petuhov_k]

Согласен. Но врядли, это как-то может повлиять на сравнительные тесты. Все «конкурсанты» в одинаковых условиях.

[jakobz]

Мне нужно было как-то сериализовать весьма большой кусок данных, с весьма простой структурой, желательно побыстрее. Был неприятно удивлен тем, насколько штатные сериализаторы тормозные.

~6 раз — это как-то уж слишком накладно. Может есть что-то быстрое?

[jakobz]

И еще один момент — как по мне сериализатор должен уметь напрямую писать в TextWriter, и именно так и надо его использовать. Зачем там строки промежуточные? Почему бы не делать тесты, приближенные к реальному использованию?

[corker]

спасибо, очень полезная статья

[Angelina_Joulie]

Простите, я что-то не совсем поляла, как именно вы тестируете сериализаторы.

Вы вообще что сериализируете? Какой грубины граф? Встречаются ли там повторяющие типы? Зацикленый ли граф объектов? Размер объектов?

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

Реально, если на кубиках, вы подвесили на подъёмнике машину и нажали педаль газа.

В заключении вы написали:
1. BMW — скокрость раскручивания колеса составляет N ms
2. Lada Granta — M ms.
3. F1 — -Z ms

[petuhov_k]

Я в самом начале статьи указал, что статья есть не детальный обзор, и тесты проводились под те потребности, с которыми столкнулся я. Когда у меня появится потребность в сравнении функциональных возможностей сериализаторов, я напишу об этом статью, если Вы не сделаете этого раньше.

На типы объектов можно посмотреть, открыв исходный код теста — ссылка есть в статье.