In the interest of sparking a little discussion (not too spicy please, we’re having a nice clean start here) I thought I would ask the question. It’s something I’m legitimately wondering about as someone who has reached for tokio by default for years.
I’m aware of async-std and smol, probably unaware of others. If you’ve used or prefer a different async runtime, what trade-offs might I be interested in or what features am I missing out on?
This won’t really help you consider another runtime specifically, but it is an instance of not choosing Tokio.
When I was benchmarking with Tokio I found it had quite a difference (higher cpu usage) to other options I was exploring. My specific use-case was an async single-threaded application which does mostly network io + timers. I would be interested to see how Tokio fairs today (I tested it over a year ago) and quite possibly any advice or tips in writing efficient code with it. My benchmark was send/recv with a UDP socket and print out stats in a timer (that’s the core idea of what I needed to use it with). Comparing both CPU usage and maximum throughput.
For normal async, I would probably still reach for Tokio, but the use case I was looking at was very much specific to what I was working on at my job (still am), and lower CPU usage as well as higher throughput is what we needed. We ended up building a small internal runtime that uses mio, it was also fun to implement. In the benchmarks we ran, it used less CPU % than Tokio, and achieved higher throughput, by enough that we thought it was worth continuing to use our internal one.