Calling the parsing function could have been done without the ugly table
using |eval|, but this seemed to degrade performance significantly (by
about 3 %). This is probably because engines optimize badly in presence
of |eval|.
The method used in this patch does not change the benchmark suite
execution speed statistically significantly on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 38.24 kB/s 38.28 kB/s
2 38.35 kB/s 38.15 kB/s
3 38.43 kB/s 38.40 kB/s
4 38.53 kB/s 38.20 kB/s
5 38.25 kB/s 38.39 kB/s
---------------------------------
Average 38.36 kB/s 38.39 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.151 Safari/534.1
The previous default name was "exports.parser". This meant that to use
the generated parser in Node.js, you had to use code like this:
var parser = require("./my-cool-parser").parser;
parser.parse(...);
Now you can shorten it a bit:
var parser = require("./my-cool-parser");
parser.parse(...);
The shorter version makes sense since no other objects except the parser
are exported from the module.
Originally I wanted to be very explicit with accesses to global object,
but since all this file is about extending it, the |global.| qualifier
seems more like noise.
Require PEG only in the "parser" task -- it may not exist when executing
the "build" task. Also don't make the "build" task dependent on the
"parser" to break a dependency circle.
Or, swapped Ruby dependency for a Node dependency.
The build script was also modified to always regenerate the parser (in
case of the "parser" task) or rebuild the library (in case of the
"build" task) even if the source files were not modified. Not doing this
led to problems when the generating code changed but the files didn't
(which happened often during development).
This patch prevents portability problems. In particular, it fixes a
problem where "SyntaxError: Invalid range in character class." error
appeared when using command-line version on Widnows (see GH-13).
Before this commit, uniqueness was checked when addding the failure. Now
we make the entiries unique when generating the error report, saving a
little time when the parsing is successful. This does not increase the
benchmark numbers too much though.
Results of benchmark with 100 runs on V8:
Before: 37.25 kB/s
After: 37.41 kB/s
Speedup: 0.241 %
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.3 (KHTML, like
Gecko) Chrome/6.0.472.63 Safari/534.3
This is a small win performance-wise.
Results of benchmark with 100 runs on V8:
Before: 31.65 kB/s
After: 32.83 kB/s
Speedup: 3.728 %
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4
Passing the context is not necessary, global variable is good enough
(passing the context would make more sense if each AST node was
translated into a function call, but this isn't the case).
The performance gain is very small, on the border of statstical error.
Results of benchmark with 100 runs on V8:
Before: 31.49 kB/s
After: 31.57 kB/s
Speedup: 0.254 %
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4
David Majda