There are a number of JSON libraries available for Erlang, and it\'s not clear to me which have the best performance characteristics (and, secondarily, ease of use), especially
I use rfc4627.erl (I stumbled upon it, and performance has not been an issue)
However, I do expect the different native erlang libraries to perform similarly well. They share ideas (as witnessed in the code comments). AFAIK mochijson
and rfc4627
share the same source erlang format.
eep018 is C, and as it is striving to implement ... hrm ... eep-0018, the term_to_json
native encoder that might be included in a future version of Erlang. Never tried it and doesn't seem actively maintained.
My final recommendation is go with mochiweb's mochijson(2). It is the de facto standard and actively maintained, used by, among others, CouchDB and Facebook.
As for choosing between mochijson
and mochijson2
, this might help you.
Try https://github.com/si14/erl_json_test erlang json benchmarks. It included benchmarks for:
List item
JSONX
Jiffy
Mochijson2
JSX
Hopefully this answer won't be ill-received, however:
I too looked into JSON parsing and serialization for a project. I had to process a lot of data in parallel, so Erlang sounded great! But a lot of that was dealing strings in the form of JSON data, and that's where things went sour.
As you probably know strings in Erlang are full fledged lists of characters. Unlike strings in most languages (a char is "about" a byte), each character in Erlang is represented by a whole 32-bit integer! So, already your strings are quite large.
Because it's a list, access to a given element of the string is O(N) instead of O(1) as you'd expected in an array of Chars. And, because strings are immutable in Erlang simple concatenation can end up being a very slow process. In the end I realized I was simply trying to use the wrong language.
In all likelihood you already know all of these things, but I felt it was useful to leave this as an answer for others who may at arrive at your post in the future.
I've been using jsonerl lately. It's based on mochijson2 and is much more easy and intuitive to use.