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.
