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.
