Wastrel's AOT WebAssembly Compiler Achieves GC Performance Edge Over V8

The WebAssembly ecosystem continues to evolve rapidly, and one of the most intriguing developments comes from Andy Wingo's Wastrel project. In a recent update, Wingo announced that Wastrel's ahead-of-time (AOT) WebAssembly compiler now supports managed memory through garbage collection, marking a significant milestone for the project.

The demonstration begins with the classic "hello, world" example, but quickly moves to more substantial benchmarks. The gcbench microbenchmark, a standard garbage collection performance test, reveals Wastrel's capabilities. Running with statistics enabled, the benchmark completes in just 138 milliseconds, performing 32 major collections with a peak heap size of 26.7 MB. The median pause time sits at a modest 0.368 milliseconds, with a maximum of 0.800 milliseconds.

But the real question emerges: how does this compare to established JavaScript engines like V8? The comparison reveals surprising results. When running the same gcbench benchmark through Node.js with V8, the engine consumes more CPU time (230ms versus Wastrel's 209ms) and more wall-clock time (200ms versus 138ms). Memory usage tells an even starker story - V8 requires 48 MB of managed memory compared to Wastrel's 26.7 MB, with the total process consuming 88 MB versus Wastrel's 34 MB.

The performance gap widens dramatically with more complex benchmarks. The quads test, which constructs and manipulates quad trees, showcases Wastrel's advantages most clearly. Wastrel completes the test in 849 milliseconds using 141 MB of memory, while V8 requires 2,460 milliseconds and 383 MB. This represents nearly a three-fold improvement in both speed and memory efficiency.

What accounts for this performance differential? Wingo suggests several factors. First, Wastrel's AOT compilation approach allows for static allocation of type checks and object shapes, enabling the compiler to optimize more aggressively. The comparison isn't entirely apples-to-apples - V8 includes on-the-fly compilation time, and there may be tiering effects at play. Additionally, Wastrel uses WTF-8 byte arrays for strings, while Node.js uses JavaScript strings, though Wingo notes this likely isn't a significant factor given the nature of these benchmarks.

The achievement is particularly noteworthy given Wastrel's current status as "demo-quality" software. Wingo emphasizes that this functionality was only recently completed, yet it's already demonstrating competitive performance against mature engines like V8. The project builds on foundations laid in earlier work, including an October introduction to Wastrel and a recent FOSDEM presentation.

For developers interested in exploring Wastrel, the setup process is straightforward. The project can be cloned from Codeberg and built using standard development tools. The examples directory contains both the simple string demonstration and the more complex benchmarks discussed here.

This development represents more than just another WebAssembly compiler - it suggests that AOT compilation approaches may offer significant advantages for garbage-collected WebAssembly programs. As the WebAssembly ecosystem continues to mature, tools like Wastrel that push the boundaries of what's possible with ahead-of-time compilation will likely play an increasingly important role in shaping the future of high-performance web applications and beyond.

The implications extend beyond mere performance metrics. Wastrel's success demonstrates that WebAssembly's garbage collection proposal, when combined with thoughtful compilation strategies, can deliver both the safety guarantees of managed memory and the performance characteristics traditionally associated with lower-level languages. This could open new possibilities for developers seeking to build complex, memory-intensive applications that run efficiently across diverse platforms.

As Wingo notes, more details will follow in subsequent posts. For now, the Wastrel project stands as a compelling proof-of-concept that challenges assumptions about the performance trade-offs inherent in garbage-collected WebAssembly, and points toward an exciting future for the technology.