jddurand
commented
2 years ago So I tried by reducing the number of terminals in the grammar. In JSON, a part of the grammar that I can safely optimize is the string. In all previous tests this was:
string ::= '"' string_parts '"'i.e. always at least three terminals.
I made an evolution to ESLIF to do regular expression substitution in addition to regular expression match. In other words I can now say that a terminal value is a substitution done directly by the regular expression engine: the processing to remove the surrounding double quotes still exist but:
- is very fast (done by PCRE2)
- allows me to do one alternative complete for strings instead of three (reducing the parse length by probably a big factor: strings are the most common things in JSON, it is always the key of an object, and very often a value)
Concentrating only on the most probable strings that are basic strings, i.e. those that contain no escaped character, the string part of the grammar becomes:
:symbol ::= /"([^"\\\x00-\x1F]*)"/u -> '$1' name => BASIC_STRING priority => 1
string ::= $BASIC_STRING | '"' string_parts '"'and the result is indeed much better: the ESLIF's PP version now always perform better than JSON::PP, getting closer to the wanted linearity:
1. Without regex substitution optimization (i.e. always at least 3 terminals for a string): a. On a short stream /home/jdurand/git/Marpa--R2/blog/json/test.json :
Rate JSON::PP ESLIF JSON PP JSON::XS
JSON::PP 1347/s -- -2% -99%
ESLIF JSON PP 1370/s 2% -- -99%
JSON::XS 124842/s 9170% 9014% --b. On a long stream:
ESLIF JSON PP 1.32/s -- -28% -99%
JSON::PP 1.85/s 40% -- -98%
JSON::XS 109/s 8136% 5791% --2. With regex substitution optimization (i.e. almost always 1 terminal for string): a. On a short stream /home/jdurand/git/Marpa--R2/blog/json/test.json :
JSON::PP 1347/s -- -18% -99%
ESLIF JSON PP 1643/s 22% -- -99%
JSON::XS 123675/s 9084% 7427% --b. On a long stream:
JSON::PP 1.85/s -- -6% -98%
ESLIF JSON PP 1.96/s 6% -- -98%
JSON::XS 106/s 5635% 5316% --In conclusion, the parse length is a factor, obviously. I am probably near to close the ticket ;)
jeffreykegler
After a couple of benchmarks, it seems that there is a non-linearity in the speed of the ESLIF built-in JSON parser. In the benchmarks included, note the relative speeds of SLIF JSON, JSON::PP and JSON::XS remain roughly the same, while the performance of ESLIF JSON plummets from better than JSON::PP to worse than the SLIF JSON.
Small file benchmark: https://gist.github.com/jeffreykegler/cdf4f8eceb07fcedb9d5dc52bd69a56a
Large file benchmark: https://gist.github.com/jeffreykegler/895e4136578ec9563468e6c103d1b9ae