Fixes the following JSHint errors:
./src/parser.js: line 460, col 50, Expected '!==' and instead saw '!='.
./src/parser.js: line 486, col 42, Expected '!==' and instead saw '!='.
Fixes the following JSHint errors:
./src/parser.js: line 193, col 18, Missing semicolon.
./src/parser.js: line 407, col 20, Missing semicolon.
./src/parser.js: line 2493, col 18, Missing semicolon.
./src/parser.js: line 2759, col 40, Missing semicolon.
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.
Fixes the following JSHint errors:
./src/utils.js: line 108, col 2, Unnecessary semicolon.
./src/utils.js: line 128, col 39, Missing semicolon.
./src/utils.js: line 140, col 4, Missing semicolon.
Fixes the following JSHint errors:
./src/utils.js: line 76, col 20, 'escapeChar' is already defined.
./src/utils.js: line 77, col 16, 'length' is already defined.
./src/utils.js: line 80, col 17, 'escapeChar' used out of scope.
./src/utils.js: line 80, col 80, '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
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.
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
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
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.
David Majda