Performance of std.json

[David Soria Parra via Digitalmars-d]

On Monday, 2 June 2014 at 19:05:15 UTC, Chris Williams wrote:

> In general, I've been pretty happy with vibe.d, and I've heard 
> that the parser speed of the JSON implementation is good. But I 
> must admit that I found the API to be fairly obtuse. In order 
> to do much of anything, you really need to 
> serialize/deserialize from structs. The JSON objects themselves 
> are pretty impossible to modify.
>
> I haven't looked at how vibe's parser works, but any very-fast 
> parser would probably need to support an input stream, so that 
> it can build out data in parallel to I/O, and do a lot of 
> manual memory management. E.g. you probably want a stack of 
> reusable node buffers that you use to add elements to as you 
> scan the JSON tree, then clone off purpose-sized nodes from the 
> work buffers when you encounter the end of the definition. 
> Whereas, the current implementation in std.json only accepts a 
> complete string and for each node starts with no memory and has 
> to allocate/reallocate for every fresh piece of information.
>
> Having worked with JSON libraries quite a bit, the key to a 
> good one is the ability to refer to paths through the data. So 
> besides the JSON objects themselves, you need something like a 
> "struct JPath" that represents an array of strings and size_ts, 
> which you can pass into get, set, has, and count methods. I'd 
> view the lack of that as the larger issue with the current JSON 
> implementations.


I think the main question is, given that std.json is close to be 
unusable for anything serious due to it's poor performance, can 
we come up with something faster that has the same API. I am not 
sure what phobos take on backwards compatibility is, but I'd 
rather keep the API than breaking it for whoever is using 
std.json.