-
Notifications
You must be signed in to change notification settings - Fork 648
async is not zero-cost #1571
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
Comments
CC @cramertj, @stjepang since TLS came up in rust-lang/rust#59119. |
thread_local! {
- static TLS_WAKER: Cell<Option<NonNull<Waker>>> = Cell::new(None);
+ static TLS_CX: Cell<Option<NonNull<Context<'static>>>> = Cell::new(None);
} Wasn't TLS before? |
@kpp I feel you're coming off rather hostile here. Even if you didn't intend to come off that way, the fact that it can be interpreted as such adds unnecessary tension to what is essentially a bug report. I'm sure the futures team would be happy to help get at the bottom of any (perceived) performance regressions, as everyone here wants async rust to be as good as possible. But that requires at the very least we maintain a base level of respect towards each other. |
I am sorry, I did not want to hurt anyone. From Urban Dictionary:
@yoshuawuyts I was told about this meaning in a private conversation. I am not a native English speaker, I did not mean to hurt anyone. |
One easy answer here is that the structure we generate for I'm going to close this issue, since it doesn't really represent any particular bug. The other bits of work I've mentioned above (generator representation, TLS) are already tracked in other issues. |
Thanks |
@kpp No worries, glad it was just a misunderstanding! |
To be clear, the issue isn't with the word "congrats" (which is fine). The issue is that it portrayed futures-rs as competing with async/await, which isn't correct: the futures-rs team works closely together with the Rust lang team, and people like @alexcrichton have done a lot of work on futures-rs and the Rust compiler. So it's not really competing at all, there's a lot of overlap between futures-rs and Rust itself. |
See my post https://www.reddit.com/r/rust/comments/bi9yzs/async_is_not_zerocost/.
Long story short, given the most simple function future::ready among all combinators:
I benchmarked it against https://rust-lang-nursery.github.io/futures-api-docs/0.3.0-alpha.15/futures/future/fn.ready.html. with:
Conclusion:
futures-rs is ~1.85 faster than async version of
ready
without lto and ~1.20 times faster with lto.I hope the compiler and futures-rs teams will dig into what's going on and why
async fn
slows down the code a little bit.The text was updated successfully, but these errors were encountered: