Fastest JSON parser in the world is a D project

Marco Leise via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Fri Oct 16 09:04:38 PDT 2015


Am Thu, 15 Oct 2015 18:46:12 +0200
schrieb Sönke Ludwig <sludwig at rejectedsoftware.com>:

> Am 14.10.2015 um 09:01 schrieb Marco Leise:
> > […]
> > 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.)
> 
>  From when are the numbers for stdx.data.json? The latest results for 
> the pull parser that I know of were faster than RapidJson:
> http://forum.dlang.org/post/wlczkjcawyteowjbbcpo@forum.dlang.org

You know, I'm not surprised at the "D new lazy Ldc" result,
which is in the ball park figure of what I measured without
exceptions & line-numbers, but the Rapid C++ result seems way
off compared to kostya's listing. Or maybe that Core i7 doesn't
work well with RapidJSON.

I used your fork of the benchmark, made some modifications
like adding taggedalgebraic and what else was needed to make
it compile with vanilla ldc2 0.16.0. Then I removed the flags
that disable exceptions and line numbers. Compilation options
are the same as for the existing gdc and ldc2 entries. I did
not add " -partial-inliner -boundscheck=off -singleobj ".

> Judging by the relative numbers, your "fast" result is still a bit 
> faster, but if that doesn't validate, it's hard to make an objective 
> comparison.

Every value that is read (as opposed to skipped) is validated
according to RFC 7159. That includes UTF-8 validation. Full
validation (i.e. readJSONFile!validateAll(…);) may add up to
14% overhead here.

-- 
Marco



More information about the Digitalmars-d-announce mailing list