It’s a pretty interesting problem. While everyone assumed that futures are lightweight and thereby more efficient than threads, there’s a couple interesting performance gotchas like this one that apply for certain libraries and applications.
Due to those I’m still m curious for how many applications the async model is actually a net win or a net loss. Too bad we don’t have time to implement all applications in both ways to gather more data.
My current practice is to sprinkle `Box::pin` on code paths that are less common (fallbacks, error handling) or expensive anyway. This cuts down the inlined state considerably without actually causing that many allocations.
It’s a pretty interesting problem. While everyone assumed that futures are lightweight and thereby more efficient than threads, there’s a couple interesting performance gotchas like this one that apply for certain libraries and applications.
Due to those I’m still m curious for how many applications the async model is actually a net win or a net loss. Too bad we don’t have time to implement all applications in both ways to gather more data.
I wish there was a Clippy lint for this (https://github.com/rust-lang/rust-clippy/issues/5263).
My current practice is to sprinkle `Box::pin` on code paths that are less common (fallbacks, error handling) or expensive anyway. This cuts down the inlined state considerably without actually causing that many allocations.