On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote:
The test is pretty simple: Parse a JSON object, containing an
array of 1_000_000 3D coordinates in the range [0..1) and
average them.
The performance of std.json in parsing those was horrible still
in the DMD 2.066 days*:
DMD : 41.44s, 934.9Mb
Gdc : 29.64s, 929.7Mb
Python : 12.30s, 1410.2Mb
Ruby : 13.80s, 2101.2Mb
Then with 2.067 std.json got a major 3x speed improvement and
rivaled the popular dynamic languages Ruby and Python:
DMD : 13.02s, 1324.2Mb
In the mean time several other D JSON libraries appeared with
varying focus on performance or API:
Medea : 56.75s, 1753.6Mb (GDC)
libdjson : 24.47s, 1060.7Mb (GDC)
stdx.data.json: 2.76s, 207.1Mb (LDC)
Yep, that's right. stdx.data.json's pull parser finally beats
the dynamic languages with native efficiency. (I used the
default options here that provide you with an Exception and
line number on errors.)
A few days ago I decided to get some practical use out of my
pet project 'fast' by implementing a JSON parser myself, that
could rival even the by then fastest JSON parser, RapidJSON.
The result can be seen in the benchmark results right now:
https://github.com/kostya/benchmarks#json
fast: 0.34s, 226.7Mb (GDC)
RapidJSON: 0.79s, 687.1Mb (GCC)
(* Timings from my computer, Haswell CPU, Linux
Very impressive.
Is this not quite interesting ? Such a basic web back end
operation, and yet it's a very different picture from those who
say that one is I/O or network bound. I already have JSON files
of a couple of gig, and they're only going to be bigger over
time, and this is a more generally interesting question.
Seems like you now get 2.1 gigbytes/sec sequential read from a
cheap consumer SSD today...
