Performance of std.json

[Chris Williams via Digitalmars-d]

On Monday, 2 June 2014 at 20:10:52 UTC, David Soria Parra wrote:
> 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.

std.json really only has two methods parseJson and toJson. Any 
implementation is going to have those two methods, so in terms of 
not breaking anything, you're pretty safe there.

Since it doesn't have any methods except those two, it really 
comes down to the underlying data structure. Right now, you have 
to read the source and understand the structure in order to 
operate on it, which is a hassle, but is presumably what people 
are doing. So maintaining the current structure would be the key 
necessity. I think that limits the optimizations which could be 
performed, but doesn't make them impossible.

Adding a stream-based parsing method would probably be the main 
optimization. That adds to the API, but is backwards compatible.

The module has a lot of inner methods and recursion. Reducing the 
number of function calls, using manual stack management instead 
of recursion, etc. might give another significant gain. How 
parseJson() works is irrelevant to the caller, so all of that can 
be optimized to the heart's content.