Performance of std.json

[Jonathan M Davis via Digitalmars-d]

On Mon, 02 Jun 2014 19:13:07 +0000
Sean Kelly via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> 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.

Agreed, though it might make sense to have something even lower level than a
SAX parser. Certainly, for XML, I'd implement something that just gave you a
range of the attributes without any consideration for what you might do with
them, whereas it's my understanding that a SAX parser uses callbacks which
triggered when it finds for what you're looking for. A SAX parser and DOM
parser could then be built on top of the simple range API.  I'd be looking to
do something similar with JSON were I implementing a JSON parser, though since
JSON is a bit different from XML in structure, I'm not quite sure what the
lowest level API which would still be useful would be.  I'd have to think
about it. But in principle, I agree with what you're suggesting.

- Jonathan M Davis