RKrklaehn·Jul 19, 2023
Anecdotal evidence, but many large rust async code bases perform significantly better if you are using a single threaded runtime vs. a multithreaded runtime.
Here is an issue for the quinn crate that implements QUIC: https://github.com/quinn-rs/quinn/issues/1433
We have had very similar experiences when developing https://github.com/n0-computer/iroh
And this is with quinn still carrying around the synchronization primitives to make everything Send.
Another piece of anecdotal evidence: the functional collection library https://github.com/bodil/im-rs comes in two flavours: one using Arc and one using Rc. The reason for this is that you get a significant performance increase by using Rc (where manipulating the refcount is just an integer inc/dec) vs Arc where manipulating the refcount needs to be an atomic op.
Last but not least - often maki
Read the rest
ng futures Send requires you to box your futures. Send and lifetimes just does not play well together. Do something like this:
trait Foo {
type OpFut<'a>: Future<Output = ()> + 'a;
fn op(&self) -> Self::OpFut<'_>
}
This is what eventually you would want something like async_trait to desugar to. Use the above in a Send context, and you get a completely undecipherable higher-ranked lifetime error. So you are back to boxing all futures.