Performance of std.json

Sönke Ludwig via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 3 01:02:35 PDT 2014


Am 02.06.2014 21:13, schrieb Sean Kelly:
> The vibe.d parser is better, but it still creates a DOM-style
> tree of objects, which isn't acceptable in some circumstances.  I
> posted a performance comparison of the JSON parser I created for
> work use with std.json a while back, and mine is almost 100x
> faster than std.json in a simple test and allocates zero memory
> to boot:
>
> http://forum.dlang.org/thread/cyzcirslzcgnyxbyzycc@forum.dlang.org#post-gxgeizjsurulklzftfqz:40forum.dlang.org
>
>
> I haven't tried it vs. the vibe.d parser, but I suspect it will
> still beat it by an order of magnitude or more because of the not
> allocating thing.
>
> I've said this a bunch of times, but what I want to see is a
> SAX-style parser as the bottom layer with an optional DOM-style
> parser built on top of it.  Then people who want the tree
> generated can get it, and people who want performance or don't
> want allocations can get that too.  I'm starting to wonder if I
> should just try and get permission from work to open source my
> parser so I can submit it.  Parsing JSON really isn't terribly
> difficult though.  It shouldn't take more than a few days for one
> of the more parser-oriented people here to produce something
> comparable.

Since some time, the vibe.d parser can directly serialize from and to 
string form, circumventing the DOM step and without unnecessary 
allocations. But I agree that an intermediate SAX layer would be nice to 
have. Maybe even an additional StAX layer.


More information about the Digitalmars-d mailing list