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.
