fix(transformer/async-to-generator): arguments isn't correct after transformation#7234
Conversation
Your org has enabled the Graphite merge queue for merging into mainAdd the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix. You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link. |
CodSpeed Performance ReportMerging #7234 will degrade performances by 10.17%Comparing Summary
Benchmarks breakdown
|
0476547 to
1de58d2
Compare
1de58d2 to
52b99d2
Compare
arguments isn't correct after transformation
b78a431 to
43e9c99
Compare
43e9c99 to
b56cc1a
Compare
There was a problem hiding this comment.
I've squashed the 3 commits and rebased on main, updating the code to take into account #7300. I caused that problem by delaying in reviewing this, so I've cleaned up the mess I made!
I can't say I really understand the logic of async function transform, so can't give a review on the "meat" of this PR. I've pushed a few commits with small optimizations and style nits. Feel free to revert any of them that you don't like.
I assume the perf impact is due to string comparisons on every single IdentifierReference and BindingIdentifier. Not much we can do about that at present I don't think.
I do think the fixtures should be altered, but @Dunqing feel free to merge and then do that in follow-up PR if you prefer.
...ance/tests/babel-plugin-transform-async-to-generator/test/fixtures/arguments/assign/input.js
Show resolved
Hide resolved
...ests/babel-plugin-transform-async-to-generator/test/fixtures/arguments/nested-block/input.js
Show resolved
Hide resolved
76076d0 to
73e082f
Compare
73e082f to
3aa07f7
Compare
Merge activity
|
…transformation (#7234) Fix due to this plugin transforming the async method and async arrow function, it caused arguments no longer point the original function. For example: Before ```js class Cls { async method() { () => { console.log(arguments) } } } ``` After: ```js class Cls { method() { var _arguments = arguments; return babelHelpers.asyncToGenerator(function* () { () => { console.log(_arguments); }; })(); } } ``` In this way, the `_arguments` is its original function's arguments ### For performance regression It seems we need to check the IdentifierReference and BindingIdentifier if it's an `arguments`, that causes a significant regression, we may need a cheap way to do checking
3aa07f7 to
7d75130
Compare
… aid inlining (#7322) Move the cheap "does arguments need to be transformed" checks introduced in #7321 into `enter_identifier_reference` and `enter_binding_identifier`, and mark those methods `#[inline]`. These hot paths can then usually execute without a function call. This wins back the other half of the perf hit of #7234.
…transformation (#7234) Fix due to this plugin transforming the async method and async arrow function, it caused arguments no longer point the original function. For example: Before ```js class Cls { async method() { () => { console.log(arguments) } } } ``` After: ```js class Cls { method() { var _arguments = arguments; return babelHelpers.asyncToGenerator(function* () { () => { console.log(_arguments); }; })(); } } ``` In this way, the `_arguments` is its original function's arguments ### For performance regression It seems we need to check the IdentifierReference and BindingIdentifier if it's an `arguments`, that causes a significant regression, we may need a cheap way to do checking
… aid inlining (#7322) Move the cheap "does arguments need to be transformed" checks introduced in #7321 into `enter_identifier_reference` and `enter_binding_identifier`, and mark those methods `#[inline]`. These hot paths can then usually execute without a function call. This wins back the other half of the perf hit of #7234.
… aid inlining (#7322) Move the cheap "does arguments need to be transformed" checks introduced in #7321 into `enter_identifier_reference` and `enter_binding_identifier`, and mark those methods `#[inline]`. These hot paths can then usually execute without a function call. This wins back the other half of the perf hit of #7234.
… aid inlining (#7322) Move the cheap "does arguments need to be transformed" checks introduced in #7321 into `enter_identifier_reference` and `enter_binding_identifier`, and mark those methods `#[inline]`. These hot paths can then usually execute without a function call. This wins back the other half of the perf hit of #7234.
…transformation (#7234) Fix due to this plugin transforming the async method and async arrow function, it caused arguments no longer point the original function. For example: Before ```js class Cls { async method() { () => { console.log(arguments) } } } ``` After: ```js class Cls { method() { var _arguments = arguments; return babelHelpers.asyncToGenerator(function* () { () => { console.log(_arguments); }; })(); } } ``` In this way, the `_arguments` is its original function's arguments ### For performance regression It seems we need to check the IdentifierReference and BindingIdentifier if it's an `arguments`, that causes a significant regression, we may need a cheap way to do checking
…transformation (#7234) Fix due to this plugin transforming the async method and async arrow function, it caused arguments no longer point the original function. For example: Before ```js class Cls { async method() { () => { console.log(arguments) } } } ``` After: ```js class Cls { method() { var _arguments = arguments; return babelHelpers.asyncToGenerator(function* () { () => { console.log(_arguments); }; })(); } } ``` In this way, the `_arguments` is its original function's arguments ### For performance regression It seems we need to check the IdentifierReference and BindingIdentifier if it's an `arguments`, that causes a significant regression, we may need a cheap way to do checking

Fix due to this plugin transforming the async method and async arrow function, it caused arguments no longer point the original function.
For example:
Before
After:
In this way, the
_argumentsis its original function's argumentsFor performance regression
It seems we need to check the IdentifierReference and BindingIdentifier if it's an
arguments, that causes a significant regression, we may need a cheap way to do checking