Labeled expressions lead to more maintainable code and also will allow
certain optimizations (we can ignore results of expressions not passed
to the actions).
This does not speed up the benchmark suite execution statistically
significantly on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 28.43 kB/s 28.46 kB/s
2 28.38 kB/s 28.56 kB/s
3 28.22 kB/s 28.58 kB/s
4 28.76 kB/s 28.55 kB/s
5 28.57 kB/s 28.48 kB/s
---------------------------------
Average 28.47 kB/s 28.53 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4
I'll introduce labelled expressions shortly and I want to use ":" as a
label-expression separator. This change avoids conflict between the two
meanings of ":". (What would e.g. "foo: 'bar'" mean? Rule "foo"
matching string "bar", or string "bar" labelled "foo"?)
The mistakes weren't caught because the first one introduces a syntax
error, causing the whole test suite not to load. Unfortunately, QUnit
didn't complain so I missed this.
The real commit these changes belong to is
33a1a7c1e9.
This shouldn't have measurable effect on the benchmarks as there are no
proxy rules in the grammars the benchamrk uses. However the effect on
generated parsers' speed should be positive generally.
In most cases, code pattern
x === undefined
was transformed to
typeof(x) === "undefined"
and similarly with |!==|.
In the generated code, the condition was simply made less strict to
avoid performance penalty of string comparison (I don't think JavaScript
VMs optimize this specific pattern to avoid it).
Similar issue exists on Windows too (they have symlinks since Vista), but I
could not find how to dereference symlinks from batch files, so I did not fix
it. I guess this does not matter much given how little the symlinks are used in
the Windows world.
Closes#1.
This speeds up the benchmark suite execution by 0.18%, which may just be a
measurement error. (Standrad statistic tests would tell more, but I don't want
to mess with them now.) The code is little bit nicer this way though.
Going further and avoiding |apply| seems to slow thigs down a bit, possibly
because multiple array accesses. I may try improved version without array
accesses (where Action passes the Sequence variable names to save the results
into) sometime later.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 29.08 kB/s 28.91 kB/s
2 28.72 kB/s 28.75 kB/s
3 28.78 kB/s 28.88 kB/s
4 28.57 kB/s 28.90 kB/s
5 28.84 kB/s 28.81 kB/s
---------------------------------
Average 28.80 kB/s 28.85 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2
The action now computes the number of passed parameters during the code
generation and the parameters are declared directly as $1, $2, etc. in the
generated function.
This does not speed up the benchmark suite execution statistically significantly
on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 28.68 kB/s 29.08 kB/s
2 28.77 kB/s 28.72 kB/s
3 28.89 kB/s 28.78 kB/s
4 28.84 kB/s 28.57 kB/s
5 28.86 kB/s 28.84 kB/s
---------------------------------
Average 28.81 kB/s 28.80 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2
This does not speed up the benchmark suite execution statistically significantly
on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 28.84 kB/s 28.75 kB/s
2 28.76 kB/s 28.69 kB/s
3 28.72 kB/s 28.69 kB/s
4 28.84 kB/s 28.93 kB/s
5 28.82 kB/s 28.70 kB/s
---------------------------------
Average 28.80 kB/s 28.75 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko)
Chrome/5.0.342.9 Safari/533.2
This does not speed up the benchmark suite execution statistically significantly
on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 28.72 kB/s 28.84 kB/s
2 28.84 kB/s 28.76 kB/s
3 28.83 kB/s 28.72 kB/s
4 28.81 kB/s 28.84 kB/s
5 28.76 kB/s 28.82 kB/s
---------------------------------
Average 28.79 kB/s 28.80 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2
David Majda