[erlang-questions] erljson - a fast JSON parser in Erlang
Paulo Sérgio Almeida
Tue Jul 29 10:22:14 CEST 2008
Bob Ippolito wrote:
> 2008/7/28 Paulo Sérgio Almeida <>:
>> - 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
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
>> - 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
Ok. Thanks for the feedback.
More information about the erlang-questions