Throwing errors on mutating immutable bindings
till at tillschneidereit.net
Mon Oct 6 06:58:04 PDT 2014
On Mon, Oct 6, 2014 at 9:22 AM, Isiah Meadows <impinball at gmail.com> wrote:
> Clearly, we still have a long way to go before beating a C++ parser.
> Pretty interesting to think about, though.
This comparison, while quite informative, isn't a full answer to the
question at hand, for at least two reasons:
For startup speed, the syntax parsing mode is more important, because that
is the one that gets run over the whole file before anything executes. The
full parser only kicks in for functions that are actually executed. (Well,
there are some features that force us on a slow, full-parsing path, but
they don't apply here.) I'm pretty sure if you use `syntaxParse` instead of
`parse`, that'll somewhat widen the gap. (In a quick test, `syntaxParse` is
about 40% faster for the test file.)
On the other hand, the Acorn parser probably does a lot more work than the
builtin one: I didn't look into it, but my guess is that it builds and
returns an AST, so it has to create a substantial graph of JS objects in
addition to parsing the source. I'm not sure how easy it'd be to hack Acorn
to just do the parsing, but if doable, that'd probably close the gap
> (Also, as a side note, should this be profiled for SpiderMonkey? V8 is
> averaging about 10x native, SpiderMonkey about 3-5x V8. My spidey
> senses sense a growing gap...;-))
By all our tests (and external ones that I'm aware of) we've all but closed
the gap; check http://arewefastyet.com. This test case is quite
interesting, though - I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1078273 to investigate.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss