Throwing errors on mutating immutable bindings

Isiah Meadows impinball at gmail.com
Tue Oct 7 03:08:30 PDT 2014


On Oct 6, 2014 9:58 AM, "Till Schneidereit" <till at tillschneidereit.net>
wrote:
>
> 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.)

That is effectively access to the tokenizer. Most dedicated parsers out
there have such access.

>
> 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
considerably.

They both return the same exact format. And Acorn does the least out of
most of the JS parsers (which is also why it has the most ES6 support). If
you simply want to check out the tokenizer, Acorn has a `.tokenize()`
method.

>
>>
>>
>> (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.

Yeah...part of why I mentioned it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141007/22b6d6ce/attachment.html>


More information about the es-discuss mailing list