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