Библиотеки Erlang JSON: производительность сериализации?

Question

Для Erlang доступно несколько библиотек JSON, и мне неясно, какие из них имеют лучшие характеристики производительности (и, во-вторых, простоту использования), особенно для сериализации erlang-to-json.

Мой вариант использования требует как синтаксического анализа JSON, так и сериализации, но код Erlang, вероятно, будет производить как минимум на два порядка больше вывода JSON (то есть сериализации), чем он будет получать ввод.

Для справки, библиотеки, о которых я знаю, включают следующее (и могут быть другие, которые я не нашел):

• mochijson
• mochijson2
• Эрл-rfc4627
• eep0018

Answer 1

Я использую rfc4627.erl (я наткнулся на это, и производительность не была проблемой)

Однако я ожидаю, что разные нативные библиотеки erlang будут работать одинаково хорошо. Они делятся идеями (как видно из комментариев к коду ). AFAIK mochijson и rfc4627 используют один и тот же исходный формат erlang.

eep018 - это C, и, поскольку он стремится реализовать ... hrm ... eep-0018 , собственный кодер term_to_json, который может быть включен в будущем версия Эрланга. Никогда не пробовал и, похоже, активно не поддерживается.

Моя последняя рекомендация - использовать mochiweb's mochijson (2). Это стандарт de facto , который активно поддерживается и используется, в частности, CouchDB и Facebook.

Что касается выбора между mochijson и mochijson2, , этот может вам помочь.

Answer 2

Попробуйте https://github.com/si14/erl_json_test тесты erlang json. Включены тесты для:

• Элемент списка

• JSONX

• Jiffy

• Mochijson2

• JSX

Answer 3

В последнее время я пользуюсь jsonerl . Он основан на mochijson2 и намного более прост и интуитивно понятен в использовании.

Answer 4

Надеюсь, этот ответ не будет получен, однако:

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

Как вы, наверное, знаете, строки в Erlang представляют собой полноценные списки символов. В отличие от строк в большинстве языков (символ "около" байта), каждый символ в Erlang представлен целым 32-битным целым числом! Итак, ваши строки уже достаточно велики.

Поскольку это список, доступ к данному элементу строки имеет O (N) вместо O (1), как вы и ожидали в массиве символов. И поскольку строки в Erlang неизменны, простая конкатенация может оказаться очень медленным процессом. В конце концов я понял, что просто пытаюсь использовать не тот язык.

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