Open
Bug 1347861
Opened 8 years ago
Updated 2 years ago
Consider storing hints during syntax parse
Categories
(Core :: JavaScript Engine, enhancement, P5)
Core
JavaScript Engine
Tracking
()
NEW
Performance Impact | low |
People
(Reporter: Yoric, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf)
While the syntax parser doesn't build an AST, it needs to resolve all the nasty bits of the JS syntax, including:
- finding out whether a `/` is an operator, the start of a comment, a regexp (tokenizer);
- finding out where a string/string template ends (tokenizer);
- finding out where a comment ends (tokenizer);
- extrapolating missing semicolons (parser);
- finding out whether a `{` opens a block or an object literal (parser);
- finding out where a nested function ends (parser).
The notion of "nasty bits" is very handwavy at this stage, but let's say it's related to lookahead.
When we later perform full parsing, we need to re-resolve these same nasty bits. No measure has been done at this stage, but I suspect that at least some of these nasty bits can be expensive. Now, at the cost of some memory, we could store hints in constant time (there are several ways to do this), in the tokenizer and/or in the parser, then reuse these hints (also in basically constant time) when we full parse.
Updated•8 years ago
|
Whiteboard: [qf]
Updated•8 years ago
|
Whiteboard: [qf] → [qf:p3]
Comment 1•7 years ago
|
||
Not that anyone asked, but...
> - finding out whether a `/` is an operator, the start of a comment, a regexp (tokenizer);
> - extrapolating missing semicolons (parser);
> - finding out whether a `{` opens a block or an object literal (parser);
These are already pretty fast. It's hard to imagine caching information will make them faster, because the decision is already so quick.
Automatic semicolon insertion, for instance, happens when you call matchOrInsertSemicolon and the next token isn't a semicolon or isn't on the same line. I hate ASI, but it's not exactly hard to do.
> - finding out where a string/string template ends (tokenizer);
> - finding out where a comment ends (tokenizer);
> - finding out where a nested function ends (parser).
In these cases, teleporting to the end when reparsing might be a nice speedup.
Priority: -- → P5
Updated•3 years ago
|
Performance Impact: --- → P3
Whiteboard: [qf:p3]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•