RFC: std.json sucessor

[Sean Kelly via Digitalmars-d]

On Saturday, 18 October 2014 at 19:53:23 UTC, Sean Kelly wrote:
> On Friday, 17 October 2014 at 18:27:34 UTC, Ary Borenszweig 
> wrote:
>>
>> Once its done you can compare its performance against other 
>> languages with this benchmark:
>>
>> https://github.com/kostya/benchmarks/tree/master/json
>
> Wow, the C++Rapid parser is really impressive.  I threw 
> together a test with my own parser for comparison, and Rapid 
> still beat it.  It's the first parser I've encountered that's 
> faster.
>
> C++ Rapid
> 0.499548
> 0.49978
> 0.499811
> 1.75s, 1009.0Mb
>
> JEP (mine)
> 0.49954797
> 0.49977992
> 0.49981146
> 2.38s, 203.4Mb

I just commented out the sscanf() call that was parsing the float 
and re-ran the test to see what the difference would be.  Here's 
the new timing:

JEP (mine)
0.00000000
0.00000000
0.00000000
1.23s, 203.1Mb

So nearly half of the total execution time was spent simply 
parsing floats.  For this reason, I'm starting to think that this 
isn't the best benchmark of JSON parser performance.  The other 
issue with my parser is that it's written in C, and so all of the 
user-defined bits are called via a bank of function pointers.  If 
it were converted to C++ or D where this could be done via 
templates it would be much faster.  Just as a test I nulled out 
the function pointers I'd set to see what the cost of indirection 
was, and here's the result:

JEP (mine)
nan
nan
nan
0.57s, 109.4Mb

The memory difference is interesting, and I can't entirely 
explain it other than to say that it's probably an artifact of my 
mapping in the file as virtual memory rather than reading it into 
an allocated buffer.  Either way, roughly 0.60s can be attributed 
to indirect function calls and the bit of logic on the other 
side, which seems like a good candidate for optimization.