Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upParser Performance Collection #9348
Conversation
This comment has been minimized.
This comment has been minimized.
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/9816/ |
This comment has been minimized.
This comment has been minimized.
Really nice! Please let us know when it's ready for review. |
This also fixes a bug with async functions
Fix plugin options
This avoids checking isIdentifierStart for every single token
This saves some steps, as the regex parser does not have to backtrack for character classes, but is has to for alternates
It does a lot of checks and a regex test
Instead of calling isKeyword we simple check directly if the keyword token is available
This comment has been minimized.
This comment has been minimized.
I'm done now. Added some more changes, especially the keyword change brings some performance. |
|
||
switch (env) { | ||
// Configs used during bundling builds. | ||
case "babel-parser": | ||
convertESM = false; | ||
ignoreLib = false; | ||
envOpts.targets = { |
This comment has been minimized.
This comment has been minimized.
hzoo
Jan 18, 2019
Member
It's possible we didn't add this before since Babylon was in another repo and a different config? Or I think it was actually slower before? Or it was because of browser support..
great changes, yeah object -> map/set is good There was a reason for the parser thing but it's probably browser compat |
} | ||
|
||
getPluginOption(plugin: string, name: string) { | ||
if (this.hasPlugin(plugin)) return this.plugins[plugin][name]; | ||
// $FlowIssue | ||
if (this.hasPlugin(plugin)) return this.plugins.get(plugin)[name]; |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
danez
Jan 19, 2019
Author
Member
It is because of this: facebook/flow#2751
Flow does not realize that calling has
ensures that get
will return something !=null
Other way would be just calling get and testing if != null
.
@@ -1630,7 +1631,7 @@ export default (superClass: Class<Parser>): Class<Parser> => | |||
this.match(tt.name) && | |||
(this.state.value === "type" || | |||
this.state.value === "interface" || | |||
this.state.value == "opaque") | |||
this.state.value === "opaque") |
This comment has been minimized.
This comment has been minimized.
nicolo-ribaudo
Jan 18, 2019
Member
We should enable the eslint rule to only allow ==
for null/undefined.
This comment has been minimized.
This comment has been minimized.
Looks good |
This comment has been minimized.
This comment has been minimized.
ef4
commented
Jan 22, 2019
The changes in this PR introduced a regression, see #9374. |
danez commentedJan 16, 2019
•
edited
So I tried to work on performance in the parser. I did not have any ground breaking success but found some small and minor stuff here and there.
Some of the changes might be debatable. If something feels weird to any of you feel free to mention and I can remove it.
The most impactful change here (depending on the tested source of course) is the removal of flow code from the regular parser. (Only if not using the flow plugin)
The other big improvement is compiling the parser for node 6.9 or newer only. I was surprised to see it was using all transforms. This might be a problem if someone is using the parser in an older browser without first compiling.
Overall it is a tiny bit noticeable but most changes also add to readability and understanding the code.
The changes are separated into commits to make it easier to see what belongs together.
I also tried other things like exchanging the big switch-case for an object as hashmap, but that made no difference.
I also updated the benchmark tool to work better and more consistently. babel/parser_performance@1df708c