[erlang-questions] erljson - a fast JSON parser in Erlang

[Paulo Sérgio Almeida]

Hi,

Bob Ippolito wrote:
> 2008/7/28 Paulo Sérgio Almeida <psa@REDACTED>:
>> - strings are decoded to existing atoms, or binaries otherwise;
> 
> This doesn't really seem like a great idea for the cases where your
> code expects a binary but gets an atom instead because some other part
> of the system happened to have an atom of that name. It "forces" all
> of your code to use atoms everywhere that you expect to match on
> something...

That was the idea. If I am interested in matching, I use an atom; 
otherwise I just store it to send it back later, and I don't care 
whether it was stored in atom or binary form. In fact, I can have a list 
of atoms for very frequent strings, so as to save memory when decoding, 
even if I don't care about matching them.

One relevant alternative design I forgot to mention, would be to do it 
(decode to existing atoms) only for the object keys and not strings in 
general (as I do now). Maybe it would be faster, not trying to do 
list_to_existing_atom with little chance of success. (I never tried to 
figure out the cost of this function.)

> 
>> - fast encoding to io_lists; special care is taken to see if no escaping is
>> needed, so as to reuse binaries in the structure to encode. (A sample
>> testing on a small example mostly with objects gave about 4 times faster
>> encoding than mochijson2; decoding was about the same speed).
> 
> Can you provide such an example benchmark? It would be pretty easy to
> go add a similar special case to mochijson2's encoder.

Sorry but I don't have much json around and I just made a simple test on 
a small file I downloaded. But I am sure it will improve speed. I guess 
over 99.9% of the strings don't need escaping, and traversing an 
existing list or binary is definitely faster than traversing and 
building a new one. An added advantage is less pressure on GC.

>> - encoding is liberal on allowed keys of objects; it can take integers,
>> floats, atoms, lists, binaries; but produces valid json with keys being
>> strings;
>>  - this is an example that means the current version may not produce a
>> roundtrip erlang->json->erlang, as object keys are only decoded to atoms or
>> binaries; this could possibly change; some thought and polishing needed.
> 
> I'm pretty sure this is the right thing to do, at least I've found it
> very convenient and that's how JavaScript behaves.

Ok. Thanks for the feedback.
Regards,
Paulo

> 
> -bob