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
There are now three vendor directories. The goal is to have test- and
benchmark-specific stuff is its own directories and not in the main one.
vendor
test/vendor
benchmark/vendor
The source code is now in the src directory. The library needs to be
built using "rake", which creates the lib/peg.js file by combining the
source files.
1. |PEG.Compiler| -> |PEG.compiler|
2. |PEG.grammarParser| -> |PEG.parser|
This brings us closer to the desired structure of the PEG object, which
is:
+-PEG
|- parser
+- compiler
|- checks
|- passes
+- emitter
These are the only things (together with the |PEG.buildParser| function
and exceptions) that I want to be publicly accessible -- as extension
points and also for easy testing of PEG.js's components.
We do this for two reasons:
1. To avoid bowser mechanism for interrupting long-running scripts to
kick-in (or at least to not kick-in that often).
2. To ensure progressive rendering of results in the browser (some
browsers do not render at all when running JavaScript code).
This does not change the benchmark suite execution speed statistically
significantly on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 31.04 kB/s 31.18 kB/s
2 31.26 kB/s 30.89 kB/s
3 31.15 kB/s 31.19 kB/s
4 30.52 kB/s 31.21 kB/s
5 31.00 kB/s 30.73 kB/s
---------------------------------
Average 30.99 kB/s 31.04 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4
Before this change, the start rule was the one named "start" and there
was an option to override that. This is now impossible.
The goal of this change is to contain all information for the parser
generation in the grammar itself.
In the future, some override directive for the start rule (like Bison's
"%start") may be added to the grammar.
Little change in the source grammar now does not change variables in all
the generated code. This is helpful especially when one has the
generated grammar stored in a VCS (this is true e.g. for our
metagrammar).
We want to have the rule parsing functions inside the |parse| method
because we want them to share a common environment. In the future,
initializers will be executed in this enviromnent and thus functions and
variables defined by them will be accessible to the rule parsing
functions.
Moving various private properties from the parser object into the
|parse| method was not strictly necessary, but it was a natural step
after moving the functions.
David Majda