[erlang-questions] Erlang to Python

Paul Davis <>
Sun Aug 7 10:04:20 CEST 2011


On Sun, Aug 7, 2011 at 2:02 AM, Wilson MacGyver <> wrote:
> It's based on eep0018
>
> https://issues.apache.org/jira/browse/COUCHDB-1118
>
> The author created https://github.com/davisp/jiffy
>

Loosely based on EEP0018 with modifications over time due to CouchDB
drifting and what the NIF API allows.

I have a simple test [1] for benchmarking mochijson2 and jiffy
together. I swear I had jsx in there but I'm not seeing it as a dep
just now. Either way, I'd recommend either jsx or jiffy if you're
looking for a JSON parser at the moment.

jsx is pure erlang, handles more character encodings, does streaming
encoding/decoding and follows EEP0018 more closely then Jiffy. Jiffy
follows mochijson2 more closely, only supports UTF-8 encoded JSON, but
its fairly speedy.

I'd be interested in seeing how Jiffy compares against different
languages. I've been meaning to tear out the NIF code and implement a
Python module with it to compare against simplejson but haven't gotten
around to it. If anyone wants help porting it to a different language
I'd be more than happy to field questions and pitch in.

There's also a previous implementation that for historical reasons is
called eep0018 but in reality it diverges from the EEP spec nearly as
far as Jiffy [2]. It's based on YAJL and is pretty close in terms of
speed to Jiffy but has issues when dealing with bignums and other
weird corners of JSON. This project is deprecated in favor of Jiffy.


[1] https://github.com/davisp/erljson_bench
[2] https://github.com/davisp/eep0018


> On Aug 7, 2011, at 2:51 AM, Michael Turner <> wrote:
>
>> I wrote: "the performance problem of serializing to JSON"
>>
>> Oops. JSON *de*-coding seems to be issue.
>>
>> But wasn't CouchDB the beneficiary of some NIF JSON parser 10x faster
>> than mochijson?
>>
>> -michael turner
>>
>>
>>
>> On Sun, Aug 7, 2011 at 2:12 AM, Michael Turner
>> <> wrote:
>>> Part of their problem might have been architectural:
>>>
>>> "In Erlang, the right way to do this is to spawn off a separate set of
>>> actors to manage each data structure and message pass with them to
>>> save and retrieve data. Our code was not set up this way at all, and
>>> it was clearly crippled by being haphazardly implemented in a
>>> functional style."
>>>
>>> I'd suggest a friendly request to mixpanel to open-source their
>>> now-disused Erlang code - it might be instructive both about how their
>>> code could have been better and about how Erlang might need to
>>> improve.
>>>
>>> I wonder ... what seems to be the performance problem of serializing
>>> to JSON might actually be a latency problem - if the managing process
>>> for some data wakes up every now and then, with medium-to-low
>>> priority, and re-serializes if necessary, to be ready to respond to
>>> such requests, it might make all the difference in the world. OK, it
>>> might make *some* of the difference in the world.
>>>
>>> -michael turner
>>>
>>>
>>>
>>> On Sun, Aug 7, 2011 at 1:55 AM, Robert Virding
>>> <> wrote:
>>>> Saw this on reddit. Any comments?
>>>>
>>>> http://code.mixpanel.com/2011/08/05/how-and-why-we-switched-from-erlang-to-python/
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> 
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list