Conversation
98ec2c2 to
4ef8d5c
Compare
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/11690/ |
9ba9bf8 to
591e2f2
Compare
| export function skipKey(key) { | ||
| if (this.skipKeys == null) { | ||
| this.skipKeys = {}; | ||
| } |
There was a problem hiding this comment.
I wish https://github.com/tc39/proposal-logical-assignment wasn't just stage 1 😛
There was a problem hiding this comment.
Offtopic: we still need a PR to add nullish coalescing and optional chaining.
There was a problem hiding this comment.
We can always use new stage features if you are willing to move off of them if they change (I think that one is small enough that it's fine) 😁
|
@nicolo-ribaudo I am sorry I make a typo before. It should be the
I agree with you that setting |
# Conflicts: # packages/babel-traverse/src/path/index.js
a45b6c5 to
d448180
Compare
| export const REMOVED = 1 << 0; | ||
| export const SHOULD_STOP = 1 << 1; | ||
| export const SHOULD_SKIP = 1 << 2; |
There was a problem hiding this comment.
Some great work doing this research!
I would just like to note that using bitwise flags and operators is for sure going to make contributing and reading the coding that much more difficult (for me, and I will assume some others). I think I mentioned it earlier on Slack and it's a hard call but trading off readability/performance. I don't know what else we can do other than writing comments to explain things though
In this PR we improve the performance of babel-traverse by revising the memory layout of
NodePath. It results to 10% performance gain compared to the control branch on the following test cases.I can observe this branch outperforms control branch consistently.
And the memory usage improvements due to compressing traverse flags and adding accessor methods for
inListandparentPath.The following changes are implemented:
NodePath.inListdata property, a get accessor is provided for backward compatibility (partially).NodePath.parentKeydata property, a get accessor is provided for backward compatibility (partially).NodePath.typeAnnotationdata property, it is introduced in Initialize properties to avoid hidden class thrashing. #1752 but since then it is not used by any routines. I believe it is a mistype ofNode.typeAnnotation.NodePath.shouldSkip/shouldStop/removedinto_traverseFlagsbit array, both get accessor and set accessor is provided for backward compatibility.this.skipKeysinsetContext.this.datainNodePath.constructor.In practice
inListandparentKeyshould be treated as read-only since these two properties are rewritten insetContext. The current behavior accepts one assigning these two properties.The
shouldSkip/shouldStop/removedtraverse flags are handy and turbofan would inline these simple accessors we don't introduce performance overhead here. By compressing these states into bit array we optimize the performance ofsetContext.