Wago's single-pass compiler aims to cut wasm compile memory to kilobytes, author says

A single-pass compiler walks the input once and emits machine code. Cranelift, which Wasmtime uses, does the opposite: it looks at the whole function, shuffles things around, runs optimization passes and makes globally better decisions ^[10][4]. The post is straight about the price of skipping that, saying single-pass compilers are incredibly fast to compile with but generally produce worse code ^[10].

Railshot's way of buying that quality back is to not redo work the toolchain already did. The argument is that wasm binaries often arrive already optimized, so a module out of LLVM, Rust or TinyGo has been through an optimizer before Wago ever sees it, and Railshot does not need to rediscover those decisions ^[11]. What is left is structure the format hands over for free: blocks, loops, branches, types and the operand stack ^[12].

That premise is what a buyer has to check. It holds for a release build out of Rust or TinyGo. It is weaker for hand-written wasm or a debug build with the optimizer off, because there is no upstream pass to inherit and no second pass inside Railshot to clean up after it ^[11][9].

The post publishes no measurement. The targets are written as goals, and the one production number in it sits on wazero's side of the comparison: on some larger workloads, wazero "could peak at hundreds of megabytes of memory just to compile a module", the author wrote ^[17][7]. Set that against the footprint the post is defending, which is a few kilobytes of RAM to run some wasm here and a megabyte there, with no Docker containers or micro-VMs booted ^[16]. Hundreds of megabytes against roughly a megabyte is a factor of a hundred or more, and all of it lands in compilation ^[20].

The cost case is put as a question. "Hey, if i can reduce memory usage by 10x and improve performance by 50%, surely I can cut our costs in half, right?" the author wrote ^[14]. Halving a bill on a 50 percent throughput gain needs per-request CPU to be the thing that sizes the fleet, and the post does say that more CPU costs money and more memory costs money ^[15]. The 10x applies to compile memory, so it pays where compile peaks set instance size, which is the per-request or per-tenant compile case. Compile each module once and cache it, and you meet that peak once per module.

The post names Wasmtime, Wasmer, V8 and wazero, then asks "So why would I be stupid enough to make a new wasm runtime?" ^[2][18]. It is a fair question. In my context the deciding numbers would be compile-time peak and steady-state throughput on my own module set, measured against wazero on the same hardware. The evidence offered for the gap today is the author's production experience at two companies that run isolated wasm on wazero ^[3].