Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 00c42cc:
|
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/45886/ |
| // Allow @@iterator and @@asyncIterator as a identifier only inside type | ||
| if (!this.isIterator(word) || !this.state.inType) { | ||
| this.raise(this.state.pos, Errors.InvalidIdentifier, fullWord); | ||
| } |
There was a problem hiding this comment.
The implementation of readIterator is copied from original readWord. It oversights that an iterator identifier may contain escapes and thus should not be allowed:
For example, currently Babel parses it successfully
function foo(): { @@iter\u0061tor: () => string } {
return (0: any);
}This PR focuses on performance only and I will open a new PR for that after this PR gets merged.
nicolo-ribaudo
left a comment
There was a problem hiding this comment.
This is probably less than 1% when parsing real files, but I like that it moves Flow stuff to the Flow plugin.
- Mover iterator identifier parsing to the Flow plugin - If the character is an identifier start, pass it to readWord1
a20aef9 to
00c42cc
Compare
This PR includes commits on #13256 , see here for the real diff.Edits: already rebased.This PR
moves the flow iterator
@@iteratorparsing to the flow plugin and simplifies the tokenizer state. It turns out we don't actually need to accessthis.state.isIteratoras long as we have a dedicated code path for Flow iterator. Sostate.isIteratoris removed.passes through the identifier start so we don't have to re-read the input source and test with
isIdentifierCharCurrently, when parsing a length-3 input
ab;,this.input.codePointAtis called for 5 times:getTokenFromCodereadWord1readWord1readWord1getTokenFromCodeThis PR passes through the read code point
0x61in sequence 1 forreadWord1so we can avoid reading again in sequence 2. Now if we are parsingab;, only 4codePointAtcall will be issued (1, 3, 4, 5). As we can see, the margin is diminishing for longer identifier names.Although we could do the same for escaped identifiers, I don't think it worths the efforts because escaped identifiers are rare.
Benchmark results
Combing these two tricks we see up to 4.5% performance gain on length-1 identifiers (Best case).
up to 2.5% performance gain on length-2 identifiers
and no significant performance gain on length-20 identifiers. Note that in predictable mode, the first bench suite always has significant variant and should not be taken into account.