This option enables/disables the results cache in generated parsers.
Until now, it was always enabled, but after this commit it needs to be
enabled explicitly (i.e. the |cache| option default value is |false|).
The reason is that parsing without it is *much* faster according to the
benchmark.
Note that disabling the cache breaks the linear parsing time guarantee,
meaning that with some grammars you can get exponential parsing time
with respect to the input length. This, together with the possibility of
improving the cache performance in the future, is the reason to keep it
as an option.
Speed impact
------------
Before: 214.08 kB/s
After: 827.52 kB/s
Difference: 286.54%
Size impact
-----------
Before: 1045396 b
After: 949783 b
Difference: -9.15%
(Measured by /tools/impact with Node.js v0.6.6 on x86_64 GNU/Linux.)
The "|| trick" is too brittle in this case -- it wouldn't work e.g. for
options with default value |true| and passed value |false|, enforcing
inconsistent default values handling.
This option makes the generated parser track line and column during
parsing. Tracked line and column are made available inside actions and
predicates as |line| and |column| variables.
Note that in actions these variables denote start position of the
action's expression while in predicates they denote the current
position. The slightly different behavior is motivated by expected
usage.
This simplifies the code a bit and makes the AST more regular (each node
type has a fixed set of properties). The latter may get useful later
when generalizing visitors.
|quote| is used outside of the |parse| function so it must be defined in
more outer scope.
Fixes a problem (introduced in e9d8dc8eba)
where construction of some error messages could throw an error.
This has two main benefits:
1. The knowledge about scoping params in at one designated place,
making all future adjustments in this area easier.
2. Action-related code does not handle sequences specially anymore.
Such knowledge/behavior doesn't belong there.
Before this change, knowledge about variable names was spread between
the |computeStackDepths| pass and the code emitter code. For example,
the fact that the |&...| expression needs one variable to store a
position was represented in both places.
This changes consolidates that knowledge and introduces a new
|computeVarNames| pass. This pass replaces old |computeStackDepths|
pass, does all computations realted to variable names and stores the
results in the AST. Note that some knowledge about variables
(inevitably) remained in emitter code templates.
Beside DRYing things up, this change simplifies the emitter
significantly. By storing variable names in the AST it also allows
introduction of a pass that will identify parameters passed to actions
using proper symbol tables. Right now, this is done in a hackish way
directly in the emitter, which won't work well with changes planned in
GH-69.
Fixes the following JSHint errors:
./src/emitter.js: line 95, col 21, 'name' is already defined.
./src/emitter.js: line 361, col 35, 'setReportFailuresCode' is already defined.
./src/emitter.js: line 362, col 39, 'restoreReportFailuresCode' is already defined.
./src/emitter.js: line 363, col 31, 'reportFailureCode' is already defined.
./src/emitter.js: line 393, col 38, 'setReportFailuresCode' used out of scope.Fixes the following JSHint errors:
./src/emitter.js: line 394, col 38, 'restoreReportFailuresCode' used out of scope.
./src/emitter.js: line 395, col 38, 'reportFailureCode' used out of scope.
./src/emitter.js: line 666, col 26, 'formalParams' is already defined.
./src/emitter.js: line 667, col 26, 'actualParams' is already defined.
./src/emitter.js: line 669, col 26, 'formalParams' is already defined.
./src/emitter.js: line 670, col 26, 'actualParams' is already defined.
./src/emitter.js: line 685, col 27, 'formalParams' used out of scope.
./src/emitter.js: line 686, col 27, 'actualParams' used out of scope.
./src/emitter.js: line 770, col 20, 'regexp' is already defined.
./src/emitter.js: line 784, col 22, 'regexp' used out of scope.
Also change |quote| in src/emitter.js so both are in sync.
Fixes the following JSHint errors:
./src/parser.js: line 3613, col 27, Mixed spaces and tabs.
./src/parser.js: line 3613, col 31, Unsafe character.
./src/parser.js: line 3613, col 38, Control character in string: [ .
./src/parser.js: line 3613, col 40, Control character in string: [
Fixes the following JSHint errors:
./src/parser.js: line 102, col 26, 'escapeChar' is already defined.
./src/parser.js: line 103, col 22, 'length' is already defined.
./src/parser.js: line 106, col 23, 'escapeChar' used out of scope.
./src/parser.js: line 106, col 86, 'length' used out of scope.
The speedup is marginal (if any) but let's have this anyway.
Speed impact
------------
Before: 212.49 kB/s
After: 213.01 kB/s
Difference: 0.24%
Size impact
-----------
Before: 1056976 b
After: 1058314 b
Difference: 0.12%
(Measured by /tools/impact with Node.js v0.4.8 on x86_64 GNU/Linux.)
Closes GH-50.
This is little faster than |String.prototype.match| in successful cases
since return value of |test| is just a boolean, not a special array as
with |match|.
Speed impact
------------
Before: 130.75 kB/s
After: 131.81 kB/s
Difference: 0.81%
Size impact
-----------
Before: 1059811 b
After: 1058371 b
Difference: -0.14%
(Measured by /tools/impact with Node.js v0.4.8 on x86_64 GNU/Linux.)
Before this commit, variables for saving match results and parse
positions in generated parsers were not used efficiently. Each rule
basically used its own variable(s) for storing the data, with names
generated sequentially during code emitting. There was no reuse of
variables and a lot of unnecessary assignments between them.
It is easy to see that both match results and parse positions can
actually be stored on a stack that grows as the parser walks deeper in
the grammar tree and shrinks as it returns. Moreover, if one creates a
new stack for each rule the parser enters, its maximum depth can be
computed statically from the grammar. This allows us to implement the
stack not as an array, but as a set of numbered variables in each
function that handles parsing of a grammar rule, avoiding potentially
slow array accesses.
This commit implements the idea from the previous paragraph, using
separate stack for match results and for parse positions. As a result,
defined variables are reused and unnecessary copying avoided.
Speed implications
------------------
This change speeds up the benchmark suite execution by 2.14%.
Detailed results (benchmark suite totals as reported by "jake benchmark"
on Node.js 0.4.8):
-----------------------------------
Test # Before After
-----------------------------------
1 129.01 kB/s 131.98 kB/s
2 129.39 kB/s 130.13 kB/s
3 128.63 kB/s 132.57 kB/s
4 127.53 kB/s 129.82 kB/s
5 127.98 kB/s 131.80 kB/s
-----------------------------------
Average 128.51 kB/s 131.26 kB/s
-----------------------------------
Size implications
-----------------
This change makes a sample of generated parsers 8.60% smaller:
Before:
$ wc -c src/parser.js examples/*.js
110867 src/parser.js
13886 examples/arithmetics.js
450125 examples/css.js
632390 examples/javascript.js
61365 examples/json.js
1268633 total
After:
$ wc -c src/parser.js examples/*.js
99597 src/parser.js
13077 examples/arithmetics.js
399893 examples/css.js
592044 examples/javascript.js
54797 examples/json.js
1159408 total
David Majda