I wrote a JSON library

w0rp devw0rp at gmail.com
Tue May 7 13:14:18 PDT 2013


On Tuesday, 7 May 2013 at 18:36:20 UTC, Sean Kelly wrote:

> $ main
> n = 1
> Milliseconds to call stdJson() n times: 73054
> Milliseconds to call newJson() n times: 44022
> Milliseconds to call jepJson() n times: 839
> newJson() is faster than stdJson() 1.66x times
> jepJson() is faster than stdJson() 87.1x times
>

This is very interesting. This jepJson library seems to be pretty 
fast. I imagine this library works very similar to SAX, so you 
can save quite a bit on simply not having to allocate.

Before I read this, I went about creating my own benchmark. Here 
is a .zip containing the source and some nice looking bar charts 
comparing std.json, vibe.d's json library, and my own against 
various arrays of objects held in memory as a string:

http://www.mediafire.com/download.php?gabsvk8ta711q4u

For those less interested in downloading and looking at the .ods 
file, here are the results for the largest input size. (Array of 
100,000 small objects)

std.json - 2689375370 ms
vibe.data.json - 2835431576 ms
dson - 3705095251 ms

Where 'dson' is my library. I have done my duty and made my own 
library look the worst in benchmarks. I think overall these are 
all linear time algorithms that do very similar things, and the 
speed difference is very minor. As always with benchmarks, 
mileage may vary.

Per request for examples of my library, I have produced this 
little snippet. http://pastebin.com/sU8heFXZ It's hard to 
enumerate all of the features I put in there at once, but that's 
a pretty good start. I also listed a few examples in a doc 
comment at the top of the json.d source.

The idea presented in this thread of building a nice tagged union 
reader (like std.json, vibe.d, and my own) on top of a recursive 
event (SAX-like) parser seems pretty attractive to me now. I can 
envision re-writing my own library to work on top of such a 
parser.


More information about the Digitalmars-d mailing list