-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
The generated code for function.sent
seems excessive
#15521
Comments
Hey @dead-claudia! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly. If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite. |
With #15922 we now generate this code: var _foo;
export function foo() {
return (_foo = _foo || babelHelpers.skipFirstGeneratorNext(function* () {
let _functionSent = yield;
console.log("1", _functionSent);
_functionSent = yield;
console.log("2", _functionSent);
})).apply(this, arguments);
} |
Thank you for your detailed report, the changes mentioned here I will consider including in the next PR. :) |
I just realized: my desugaring isn't correct when side-effecting default parameters are present. Those will have to be moved after the first So, that will need accounted for. |
馃捇
What problem are you trying to solve?
I'm looking through the generated code for
function.sent
, and it's generating a lot of unnecessary functions that'd get lazily compiled anyways (and thus wouldn't benefit anything).Describe the solution you'd like
Let's take this relatively simple source:
Here's how it's currently compiled as of v7.21.3:
Here's how I feel it should be compiled:
Note the following:
The helper's small enough, it might even be worth eliminating entirely for only a very slight increase in size (we're talking single digits in toy examples, wouldn't even be noticed in the real world) compared to both a simpler implementation and a possible mild increase in perf-sensitive code (due to the
.next()
call being made monomorphic):Here are the tradeoffs with that alternative approach:
.next()
call becomes obviously monomorphic, speeding up construction very slightly. (I doubt this would show up outside microbenchmarks, though.) Once engines can monomorphize calls post-inlining (I don't believe any can currently), this very slight perf advantage won't exist anymore.Longer example with 5 generators
This is written to be a little less academic and a little more real-world. You could imagine this being part of a streaming micro-framework built on top of generators. I provided gzip results of each as well to give an idea how it compresses.
Source:
Current compilation result as of v7.21.3:
My suggestion with helper:
My suggestion with no helper:
Describe alternatives you've considered
Leaving it as-is. If it ain't broke, don't fix it. This is just an optimization suggestion anyways.
Documentation, Adoption, Migration Strategy
Nothing really to document or migrate to - this is just an output optimization.
The text was updated successfully, but these errors were encountered: