perf: only apply lazy cjs module transform on cli and core #10443
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a follow-up to #7588. In this PR we apply lazy module transform only on
babel/core
andbabel/cli
so thatbabel --version
andrequire("@babel/core").loadPartialConfig
still benefit from lazy module transformationtraverse.node
. So it is marginally faster.up-front loading time comparison
Here is comparison of
babel --version
loading time between experiment and control:Experiment (this branch)
Control (master)
One can see there is no significant performance regression about up-front loading time.
Comparison of code
Here we take
traverse.node
from@babel/traverse
to analyze its impact. It is a popular execution path when transforming codes.Comparison of compiled JavaScript code
Experiment:
Control:
Apparently the only code change here is that
const keys = t().VISITOR_KEYS[node.type];
is replaced byconst keys = t.VISITOR_KEYS[node.type];
In C code, we may see no difference here since
t()
call can be inlined. However, we are not sure if it is equivalent in JavaScript executed by v8. The answer comes from turbofan optimized machine code.Comparison of the compiled x86_64 machine instructions of
traverse.node
Thanks to [print code] utility introduced in babel/parser_performance#8, we can show the compiled machine code of
traverse.node
. For brevity we list the difference only.Experiment:
Control:
Apparently, the experiment branch is more optimal than the control since we completely get rid of a JavaScript function call:
In the experiment branch, the
t
object is loaded directly intordx
and prepared to be called byLoadICTrampoline
later. While in the control branch, a function context is constructed instead and afterCall_ReceiverIsNullOrUndefined
, the returned resultrax
is later moved tordx
.