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
Disabling failure reporting is driven by the |reportFailures| variable.
So far it was a boolean and its value was saved before changing and
restored afterwards (requiring additional variable in few places). This
patch changes it to an integer where value 0 means "report errors" and
anything > 0 means "do not report errors". Instead of saving/restoring
we can now simple increment/decrement (avoiding the additional
variable and simplifying the code).
This change speeds up the benchmark suite execution by 0.66%.
Detailed results (benchmark suite totals as reported by "jake benchmark"
on Node.js 0.4.8):
-----------------------------------
Test # Before After
-----------------------------------
1 129.26 kB/s 128.28 kB/s
2 127.34 kB/s 127.53 kB/s
3 126.72 kB/s 129.01 kB/s
4 126.89 kB/s 128.05 kB/s
5 126.46 kB/s 127.98 kB/s
-----------------------------------
Average 127.33 kB/s 128.17 kB/s
-----------------------------------
The change does not change the benchmark suite execution speed
statistically significantly.
Detailed results (benchmark suite totals as reported by "jake benchmark"
on Node.js 0.4.8):
-----------------------------------
Test # Before After
-----------------------------------
1 128.20 kB/s 128.03 kB/s
2 130.36 kB/s 128.73 kB/s
3 126.53 kB/s 129.72 kB/s
4 127.46 kB/s 127.48 kB/s
5 127.63 kB/s 128.53 kB/s
-----------------------------------
Average 128.04 kB/s 125.50 kB/s
-----------------------------------
Closes GH-25.
The engine's and dependencies' versions are the ones I've tested with.
Lower version will probably work too, but I don't want to spend more
time testing now so I'll play it safe.
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.
David Majda