Performance of WebAssembly runtimes in 2023
When WebAssembly was first released I saw a number of performance claims based on micro-benchmarks (i.e. trivial algorithms executed millions of times) that were quite misleading. A realistic, and useful, benchmark needs to perform a more realistic computation. This blog post shares the results of just that, a benchmark based on a real-world crytographic algorithm.
The benchmarks were run against seven different wasm runtimes, including node and bun. Roughly 10 different algorithms were benchmarked, with the detailed results presented, as well as the cumulative benchmark (smaller = better)
The conclusions, of this post are very insightful, explaining why certain engines perform better than others and giving useful tips on which engine you might choose.
And here’s another WebAssembly engine … however, this project is more than just the engine itself, it is a collection of WebAssembly tools. These include tools for compression and conversions between formats (binary / WAT). This project is relatively new, but could be one to watch.
And here’s another early-stage project, this time looking to provide WASI and WebAssembly Component Model support for Kotlin. You can find our more about the official Kotlin roadmap for WebAssembly here.
When building web applications, many of the operations you perform are asynchronous, for example issuing an HTTP request then waiting for the response. This is a challenge when writing wasm applications, the Promise-based world of the browser doesn’t map well to the world of C/C++ for example. This blog post introduces a way of suspending wasm execution while asynchronous operations are underway.