[eeps] JSON

[Michael Truog]

On 06/30/2011 05:46 PM, Emad El-Haraty wrote:
> begin Michael Truog quotation:
>> On 06/30/2011 02:51 PM, Loïc Hoguin wrote:
>>> On 06/30/2011 11:39 PM, Robert Virding wrote:
>>>> At the Erlang Factory in London after the EEPs run-through we had a
>>>> small very informal discussion. As a result of that and after a
>>>> discussion on erlang-questions I think it is very important that we
>>>> decide something about eep-18 and JSON. I think we should propose a
>>>> standard representation and write an OTP module which implements
>>>> encoding/decoding this. The first version doesn't have to be that
>>>> fast, mochijson2 which is being used apparently isn't fast, and it can
>>>> be improved later both with better erlang and NIFs. The important
>>>> thing is that it is *there* and that it is a good representation,
>>>> otherwise we might end up with something bad just because that is all
>>>> there is.
>>> jsx is already very good. It implements the EEP and is faster and more
>>> convenient to use than mochijson2 IMHO.
>>>
>>> See https://github.com/talentdeficit/jsx
>> Eventually it may be necessary to go with a NIF to do JSON since that has been necessary with XML parsing in Erlang.  The https://github.com/benoitc/eep0018 source code may be a good start on that (haven't looked at the source code) and YAJL is a fast parser.  However, jsx is native Erlang that is faster than the other native Erlang parsers (http://okeuday.livejournal.com/18353.html, encoding could be improved a little, but decoding is better) and should have the critical parts of the EEP.  So, jsx is easier to test and should be a safer choice for satisfying the EEP.
>> _______________________________________________
>> eeps mailing list
>> eeps@REDACTED
>> http://erlang.org/mailman/listinfo/eeps
> It looks like it could use substantial improvements in encoding,
> seeing as how it is 200%-300% slower than mochijson in that area.

194-195% on the largest JSON files (5 and 6).  However, having a JSON parser in Erlang/OTP seems like a good goal and there currently isn't better Erlang code that I am aware of (that doesn't use NIFs).  The author said there were easy improvements that could be made when I mentioned it awhile ago.