-
Notifications
You must be signed in to change notification settings - Fork 620
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
join! doubles the size of the joined futures #1473
Comments
@cramertj, @tmandry: Do you think this will get fixed with the generator optimizations in rust-lang/rust#52924? Or are other optimizations needed for this? Futures uses the "move future into other place" to make it inaccessible or just in order to compose things quite often, and in the current state the sizes suffer quite a bit from that. I just replaced a |
@Matthias247 awaiting three futures in order is always going to be smaller, because you only have to save the state of one future at a time. The optimization in rust-lang/rust#60187 is designed to shrink async fns with multiple |
The join macro also puts each future in a |
An unconditional move out of the original non-Copy future should be able to be trivially optimized away by NRVO that works any good at all. However, we don't have NRVO that works any good at all today, so I'd be happy to accept any hack you can come up with that prevents these extra locals from being created. |
I experimented a bit around this with a custom Which somehow makes sense. Even if we move the |
I'm going to close this as I don't think there's anything more we can do in the |
I spent some time in investigating sizes of async functions, and discovered that the usage of
join!
lead to a doubling of the required size for a future.After looking into the associated code, I think the move/copy of the joined futures is the issue:
While this seems harmless, these operations add up, and every composition layer can double the future size. And moving futures in the 10kB+ range is costly and wasting memory.
Maybe there are other ways to do this too. E.g. requiring already pinned futures and polling these in-place? With an extra-layer that stack-pins futures that are not yet pinned?
There are probably also a few other combinators which inhibit the same behavior.
The text was updated successfully, but these errors were encountered: