Frank DENIS random thoughts.

Why compiling Rust to WebAssembly is slow

2026-08-19T00:00:00+02:00

Compiling Rust to WebAssembly with debug info is slower than it should be. Sometimes unbearably slower.

For example, here’s a 40-line Rust reproducer that takes 50 seconds to build with debug info and 1.5 seconds without it.

This reproducer was reduced from a crate (ed25519-compact) where enabling debug info made compilation ~40x slower, but the bug itself is broader and affects all Rust code compiled to WebAssembly to varying degrees.

This is actually a known LLVM bug that had already been reported and fixed for clang. But the fix is incomplete.

Debug info becomes records in the instruction list

Cargo has a debug setting to control debug info. debug = 2 asks LLVM for full DWARF information, which very few people use in practice with WebAssembly, but which people like to enable anyway (if only because debug = true is an alias for debug = 2).

This debugging data is designed for profiling a wasm binary and getting real symbol names in stack traces. It’s also the default for Rust’s dev profile.

Something important to understand first: LLVM represents a source variable’s location with a DBG_VALUE record.

The record says that, at this point in the generated code, a variable lives in a register, a stack slot, or a constant. It sits in LLVM’s machine-level intermediate representation, or MIR, and produces no code by itself.

But it’s relevant when code is moved. A debugger must see the right value, so every pass that moves an instruction has to move or update its DBG_VALUE records too.

With debug = 2, heavy inlining can produce hundreds of thousands of DBG_VALUE records in one function.

And when targeting WebAssembly, a lot of code has to be moved.

WebAssembly has to move values onto the stack

Unlike native targets, WebAssembly is a stack machine.

LLVM first generates instructions using named temporary registers, then a backend pass called “Register Stackify” moves values it can use onto the stack near the end of code generation.

A definition computes a value, while a use consumes it.

And when a definition has one use, Register Stackify can move that definition immediately before the use.

The value then stays on the wasm operand stack instead of passing through a local, which saves wasm code and runtime work.

This happens inside a basic block, a straight sequence of instructions with no branches into or out of its middle.

But as we saw before, moving a definition also means moving its debug records. This is where things start to suck.

The pass keeps rescanning the list it grows

Before it can move a definition, the pass scans from that definition to the end of its basic block for its debug records, stopping if the register is defined again.

It also scans from the definition to the place where the instruction will be inserted, collecting records for the variables it tracks.

Those are linear scans.

But repeating them for many definitions turns them into quadratic work: twice as many records can mean four times as much scanning. Yikes.

The pass also makes its own input larger as it runs.

When it sinks a definition, it leaves the old debug records in the instruction list with their locations blanked out instead of deleting them.

When a value is cheap to compute, such as a constant, it computes that value again at every use instead of carrying it around. Each copy gets fresh DBG_VALUE records. Re-yikes.

So the pass keeps adding records to the same list it keeps rescanning. It’s very inefficient and awful for large functions.

A small reproducer

That reproducer repeatedly squares a [u64; 5] through a chain of #[inline(always)] functions.

On my machine, this command:

cargo build --release --target=wasm32-unknown-unknown

produced:

Configuration	Build time
`debug = 2`	50.56s
`debug = 0`	1.55s

The 1.55 seconds is the whole cargo build time with debug info off. Adding full debug info turns the same build into a 50-second wait. Ouch!

And rustc -Z time-llvm-passes shows where it goes.

With debug = 2, LLVM pass time was 50.85s: WebAssembly Register Stackify took 43.51s, or 85.6%, and Explicit Locals took 6.31s, or 12.4%. Everything else is negligible.

With debug = 0, total pass time was 1.42s. Register Stackify took 0.96s and Explicit Locals took 0.003s, making them roughly 45x and 2000x slower with debug info.

This is all due to the inefficient handling of DBG_VALUE records.

The crate looks small and innocent: it just produces one function with one basic block.

But by the time Register Stackify is done, it has about 90k real instructions, 267k DBG_VALUE records, and 355k lines of MIR. Explicit Locals isn’t broken. It’s a linear pass that receives 350k instructions instead of 90k. Pretty bad.

LLVM’s fix is incomplete

There’s already llvm/llvm-project issue #168326, which was reported against clang and describes the same problem.

It was closed on 2026-03-27 by commit fe990b9005260bcf4a5630b577483e954c6bb60e.

The way it works is that it counts a register’s DBG_VALUE uses, then stops the forward scan after it has found them all. The counter is provided by a use list, the compiler’s unordered list of every place a value is used.

But that doesn’t help Rust (TBH it does, but very little).

The catch is that, while moving values, Register Stackify can point an existing DBG_VALUE at a different register without moving the record itself.

And after enough copies, a record near the top of the block can refer to a register defined near the bottom.

It appears in that register’s use list, yet a forward scan from the definition can never reach it. The counter includes the earlier record, so it never reaches zero.

A better fix

Here’s a better fix as a single patch that can be applied to the LLVM code that currently ships with Rust.

It contains three independent changes.

The first change is in the WebAssembly debug-record helper.

It stops Register Stackify from reading to the end of a block when it doesn’t need to.

The compiler already keeps a list of every place a value is used, including the debug records that mention it, so it knows how many records it needs to find. The old code still read forward from the definition until it reached the end of the block. After copies, some records can sit above the definition.

A forward scan can never reach them, so its count never reaches zero and it always reads to the end. That’s why LLVM’s existing change doesn’t help this Rust case.

The patch makes the thing walk upward as well as forward. The upward walk counts off records above the definition, while the forward walk keeps the same order and still stops at another definition.

Once both walks have accounted for every record, they stop. The compiler finds the same records in the same order without reading the rest of the block.

That same first change also avoids building expensive lookup keys for records it will discard. While collecting records between two points, the old code built and hashed a full identifier for every record it passed, then usually threw it away because it described a variable it didn’t track.

Now it first asks whether it cares about that variable with one cheap comparison. That reduced hash-table lookups from 27.4M to 3.0M. Pretty significant.

The second change is a non-WebAssembly-specific change.

LLVM gives real instructions position numbers so it can compare their order without walking the instruction list. But debug records never get a position number, yet the old code looked each one up before learning that it wasn’t there. The patch just skips those useless lookups. And every target benefits from it, not just WebAssembly.

The third change is back in the WebAssembly pass.

It asks a cheaper question about whether one instruction always runs before another. The general-purpose helper answered by walking the block from the beginning every time. The instructions already have position numbers, so comparing two numbers gives the same answer.

These changes don’t affect the compiled code itself at all, so there are no runtime performance regressions or behavior changes.

Let’s benchmark the reproducer again

Here are llc -O3 -time-passes measurements on the reproducer’s bitcode, the compiled form of the program that LLVM reads:

Pass	Before	After
WebAssembly Register Stackify	45.9s	1.19s
WebAssembly Explicit Locals	6.5s	0.013s
Total codegen pass time	53.3s	2.17s

With debug info disabled, Register Stackify takes 1.14s on this input. The remaining debug-info overhead in that pass is about 0.05 seconds.

End to end, debug = 2 fell from 50.56s to 2.72s.

And debug = 0 fell from 1.55s to 0.89s. Pretty cool.

Processing and emitting 267k debug records still costs time, but the quadratic blowup is gone.

Testing on real-world code

Does this affect code people actually compile? Yes.

I repeated the crate benchmark with common crates.

Every crate used the release profile with debug = 2 and codegen-units = 1.

I emitted LLVM bitcode for every crate with:

RUSTFLAGS="--emit=llvm-bc" cargo build --release --target=wasm32-unknown-unknown

Then I ran each module through both compilers:

llc -O3 -time-passes -filetype=obj -o /dev/null <crate>.bc

Both llc binaries came from the same source tree with the same build configuration. The patch was the only difference.

Cryptography

I benchmarked an app with a bunch of crypto crates: aegis, sha2, sha3, blake2, blake3, md-5, ripemd, chacha20poly1305, aes-gcm, argon2, curve25519-dalek, ed25519-compact, k256, p256, p384, ahash, etc.

	Before	After
Time in Register Stackify, all 134 modules	1702.7s	26.2s
Total wasm code generation time, all 134 modules	1922.2s	67.4s

ed25519-compact 2.4.0 alone went from 1683.4s to 23.2s in Register Stackify, and from 1884.9s to 48.2s for total code generation.

That’s 31 minutes of code generation for one ordinary crate, down to 48 seconds.

The patched compiler still spends 23 seconds in that pass. Once its field arithmetic is inlined, the crate really is enormous. The quadratic scan is what turned 23 seconds into half an hour.

Here’s a detailed benchmark for some crates:

Crate	Register Stackify before	after	Whole code generation
`ed25519-compact`	1683.4s	23.2s	39x faster
`k256`	5.06s	0.21s	4.8x faster
`blake2`	1.43s	0.21s	4.9x faster
`ripemd`	0.61s	0.064s	3.9x faster
`sha2`	3.01s	0.83s	2.8x faster
`p256`	3.22s	0.44s	2.4x faster
`p384`	0.89s	0.12s	2.3x faster
`blake3`	0.27s	0.046s	2.3x faster
`jwt-simple`	0.68s	0.073s	1.6x faster
`curve25519-dalek`	0.14s	0.021s	1.3x faster
`aegis`	0.017s	0.0028s	1.2x faster

For sha2, 88% of the crate’s entire WebAssembly code-generation time was in Register Stackify before the fix.

Non-crypto things

I also tried a bunch of compression crates (brotli, flate2, miniz_oxide, ruzstd, zopfli, libflate, lzma-rs, snap, bzip2-rs, zune-inflate, lz4_flex).

I also tried linear algebra crates (nalgebra, glam, and cgmath), and compilation got 4.3x faster.

The bug shows up everywhere, but it really gets expensive when a function gets big.

The target (wasm32-unknown-unknown, wasm32-wasip1, etc.) also doesn’t make any difference.

Who pays for it today

Rust users targeting any wasm target with debug info enabled are affected, including the default dev profile and release profiles with debug = 2 (debug = 1 isn’t affected).

C and C++ users compiling wasm with clang and -g are affected too, which is how issue #168326 in LLVM first appeared.

More codegen units or no debug info work around the problem until the patch lands, but that’s not ideal.

Is it going to be fixed once Rust updates its LLVM fork to include the fix originally made for clang?

Let’s see:

Module	Current Rust	Upstream LLVM fix	Ours
repro RegStackify	45.37s	6.32s	1.17s
repro total codegen	52.58s	7.12s	1.99s
sha2 RegStackify	3.04s	2.35s	0.83s
sha2 total codegen	3.46s	2.75s	1.21s
k256 RegStackify	5.07s	0.67s	0.22s
k256 total codegen	6.79s	1.86s	1.42s

Well… no. An LLVM update will definitely help, but not as much as the changes proposed here.

An improved attack on 7-round AES

2026-07-30T00:00:00+02:00

Recently, Milad Nasr and Nicholas Carlini used an AI model to improve an earlier attack on seven-round AES-128.

And Satoru Kanno (@satokan3) wrote a great explanation of the result in Japanese.

Here’s a walkthrough based on his blog post and my understanding of the results, in English.

TLDR: Don’t panic. It’s an incremental improvement to an impractical reduced-round attack. Full AES-128 remains unaffected.

But what’s interesting is how the researchers used an AI model to find the improvement.

What the result actually covers

Standard AES-128 has ten rounds.

But this attack stops after seven. So, this is not the real cipher. But studying reduced-round ciphers is a common practice in order to better understand the security margin of a primitive.

A better attack on seven rounds is useful research, but it says nothing alarming about the complete cipher.

The attack also needs about 2^105 carefully arranged plaintext blocks, all encrypted under the same unknown key. This is way outside the recommended (and pratical) limits of AES usage, and just streaming that many 16-byte blocks at 1 TB/s would take roughly 20 trillion years.

And an attacker would have to collect them from real network traffic. Plus, they’d need access to an encryption oracle and the ability to choose a vast number of specially structured inputs.

That’s a lot to ask! So to be clear: this scenario is completely unrealistic. There’s no practical attack here. AES remains fine.

How the research happened

Nasr and Carlini have long records in security research. In particular, they recently coauthored ExploitGym, which tests whether AI agents can turn real software vulnerabilities into working exploits.

For this project, they used a custom research scaffold, sponsored by Anthropic (AI usage cost alone for that task was evaluated to about $100,000)

It gave the model access to papers, code, and experiments, and let long searches continue between human prompts.

And the early runs concluded that AES had already been studied too thoroughly to leave an easy improvement.

So, the team kept the search focused: they changed the instructions, rejected easier targets, and pushed the model to work on a publishable attack against seven rounds.

Their scaffold even let the model modify parts of its own agent loop.

And after three days, the output from one run contained the idea that became the Möbius Bridge.

Finally, a few more days of experiments refined it into the attack described in the paper.

The paper says the model produced the bridge, the optimization techniques, and the correctness arguments. Pretty cool.

It’s important to note that the AI model did substantial work inside the system the researchers built, but it didn’t independently decide to study AES or publish a result.

Nasr and Carlini spent several hundred hours, nearly a month, checking the claims and writing the paper.

They’re the researchers responsible for the work. The Claude Mythos model was a tool they used.

The expensive byte guess

The new attack builds on a 2013 meet-in-the-middle attack.

A meet-in-the-middle attack computes forward from the plaintext and backward from the ciphertext, then looks for a match in the middle. And in this case, a large precomputed table describes a four-round core of AES.

To reach that core, the older attack had to guess selected bytes from the outer rounds.

And one of those bytes had 256 possible values. For every candidate at this stage, the attack tried all 256 values and rebuilt the data for a table lookup each time.

The Möbius Bridge

Now, here’s the cool part, the shortcut. The AES S-box made it possible.

Because the S-box isn’t an arbitrary lookup table: it first inverts each byte in a 256-element finite field, then applies a fixed affine transformation.

And at this stage, the two sides of the attack see different versions of the same collection.

If an offline difference is called d, the paper’s bridge identity is g = s^2 * d^-1 XOR s, where g is the corresponding online value and s is an unknown byte shared by the entire collection.

As a function of d, this is a particular Möbius transformation.

The researchers then take the reciprocals of the offline differences. If v = d^-1, the relationship becomes the affine map v -> s^2 * v XOR s.

The Möbius Bridge replaces the collection with a fingerprint that stays identical under that shared transformation. The individual values change, but the fingerprint doesn’t.

The attack can therefore check the precomputed table without trying all 256 values of the key byte first.

The formula in the diagram describes the relation between two collections when the surrounding key guesses are correct. It doesn’t describe complete AES states.

The bridge doesn’t remove the byte from the final key: it removes the 256-way guess from this table-lookup stage, and a later step recovers the byte.

Other key guesses remain, and bytes that pass through MixColumns don’t preserve the same convenient relation.

Removing the loop suggests a 256-fold speedup. But it’s important to note that computing the fingerprint is expensive, so some of that gain disappears.

After several optimizations, the estimated speedup is about 200 to 800 times. Pretty impressive, but once again, that has no practical impact.

The data still dominates

For the same 2^105 chosen plaintexts and a roughly 63 percent chance of success, the estimates are:

Attack	Chosen plaintext blocks	Estimated AES-equivalent work
Previous attack	`2^105`	`2^99`
Möbius Bridge	`2^105`	`2^89.3` to `2^91.4`

That’s a large reduction but the impossible 2^105 data requirement hasn’t changed, so data remains the dominant cost.

What has actually been tested

Obviously, the complete attack has never been run because it’s far too expensive. So, the researchers tested its components instead. See the code they released.

The researchers also ran an end-to-end attack on a toy cipher based on AES with a 24-bit key.

For full-size seven-round AES-128, they recovered 50 out of 50 planted keys, but it skipped the two parts that can’t be run at full scale.

It used the one table entry that should match and to identify the rare plaintext pair that the complete attack would have to find.

A Lean theorem checks the core bridge identity, while large computational experiments test the fingerprint’s behavior. Cool, but neither proves the complete attack.

We should emphasize that Anthropic published the work as a technical report rather than a peer-reviewed paper. Cryptographers outside Anthropic commented on an early draft, but broad independent review has only just begun. The full attack is too expensive to validate on actual hardware.

That being said, the work remains a clever incremental result in reduced-round AES cryptanalysis.

These results show that a capable AI model can be a useful tool when experienced people choose the problem, give it room to explore, and check every important claim.

AES gets swizzled

2026-07-16T00:00:00+02:00

There’s an old problem with AES when implemented in software: it’s either slow or insecure.

AES has a state of sixteen bytes, and a round has four steps:

SubBytes replaces every byte using the AES S-Box.
ShiftRows moves bytes to different columns.
MixColumns combines the four bytes in each column.
AddRoundKey XORs another sixteen-byte value.

And SubBytes is the annoying part, because it applies a random-looking permutation to every byte:

SBox(0x00) = 0x63
SBox(0x53) = 0xed
...

An obvious way to implement that is by using lookup tables.

But here’s the problem: the lookup indices are secret data, and accessing a cache line that was just accessed and is still in the cache is slightly faster than accessing other addresses.

Taking advantage of this, an adversary on the same machine can learn information about the secret indices. For example, DJB recovered AES keys from remote timings, and Osvik, Shamir, and Tromer demonstrated cross-process attacks against OpenSSL and disk encryption.

That was mostly solved on modern mobile, desktop, and server CPUs by adding AES instructions.

But old is new again. With new platforms such as WebAssembly, even when running on such CPUs, applications can’t use AES instructions, so they have to reimplement AES themselves. Sigh.

A common way to avoid using lookup tables is bitslicing: using a circuit of logical operations applied to a different representation of the AES state, where all the bits expected to follow the same circuit are packed together in a register.

It works very well in hardware, but in software, performance is generally still not great, especially compared to what CPU AES instructions can do.

But there’s a third option that’s surprisingly not well known and was originally described by Mike Hamburg in Accelerating AES with Vector Permute Instructions.

A lookup table inside a register

Modern CPUs, even when accessed via WebAssembly, include something nice: SIMD registers that contain 16 bytes or more.

A lot of instructions can be used with such registers, but a very common one, which (oh, joy!) is even accessible in WebAssembly, treats one 16-byte vector as a table and another as sixteen selectors:

table     = [t0, t1, t2, ... t15]
selectors = [ 3,  9,  0, ...   7]
result    = [t3, t9, t0, ...  t7]

A single instruction effectively performs sixteen lookups in parallel. The table is kept in a register, so there are no memory lookups, and (barring microarchitectural vulnerabilities) no side channels.

This is something that all CPUs with SIMD instructions support. On x86, it’s called PSHUFB, on ARM, TBL, and WebAssembly has a corresponding instruction called i8x16.swizzle, which any sane compiler can map directly to PSHUFB or TBL.

When selectors are between 0 and 15, the behavior is as expected, and the same across all targets.

Values outside that range are target-specific, which is important for WebAssembly (more about that later).

Turning 256 values into 16 by 16

The AES S-Box isn’t actually random. It’s defined as:

S(b) = A(inverse(b)) XOR 0x63

The byte is inverted in the AES finite field. Then a fixed linear bit transformation A and the constant 0x63 are applied. And the inverse of zero is defined as zero.

AES uses a finite field with 256 elements, commonly written GF(2^8). And the same field can be represented as a quadratic extension of a 16-element field:

GF(2^8) is isomorphic to GF(2^4)[t] / (t^2 + t + zeta)

With these binary encodings, field addition in both GF(2^8) and GF(2^4) is bitwise XOR.

Here zeta is chosen so that the quadratic polynomial is irreducible.

And here’s something interesting:

256 = 16 * 16

This is just a reversible change of coordinates.

And in the new representation, one byte becomes a pair of encoded four-bit field components, while addition and multiplication keep working as expected.

A linear input transformation produces those components:

lo = input & 0x0f
hi = input >> 4

encoded = lookup16(input_map_lo, lo) XOR lookup16(input_map_hi, hi)

See? The low and high nibble contributions can be looked up separately because the transform is linear.

With two permutations, we can transform all sixteen AES state bytes.

Inversion with small register tables

Hamburg’s nested-inversion construction reduces the nonlinear part of the field inverse to five small lookups:

k = low_nibble(encoded)
i = high_nibble(encoded)
j = k XOR i

ak  = lookup16(inverse_scaled, k)
iak = lookup16(inverse, i) XOR ak
jak = lookup16(inverse, j) XOR ak
io  = lookup16(inverse, iak) XOR j
jo  = lookup16(inverse, jak) XOR i

The stages use scaled and skewed representations, so treating every value as an ordinary nibble in one fixed GF(2^4) basis gives incorrect results.

So, two output tables apply the remaining factors, return to the normal AES byte basis, and apply the linear part of the S-Box affine map:

a = lookup16(output_u, io) XOR lookup16(output_t, jo)

a XOR 0x63 = AES_SBOX[input]

With the target-specific infinity handling described below, we get the correct S-Box value for every possible input byte. And we only need 16-element lookup tables. Each fits in a SIMD register. You see where this is going.

Folding the rest of the round

MixColumns is evaluated on the constant-free S-Box value a = A(inverse(input)).

It needs both a and a multiplied by 0x02 in the AES field (3a is also needed, but that’s just a + 2a).

Since that operation is linear, a second pair of output tables can produce the doubled value directly:

a2 = lookup16(output2_u, io) XOR lookup16(output2_t, jo)

Four fixed permutations gather the bytes after ShiftRows and arrange the MixColumns contributions:

m0 = permute(a2,       mix0)
m1 = permute(a XOR a2, mix1)
m2 = permute(a,        mix2)
m3 = permute(a,        mix3)

output = m0 XOR m1 XOR m2 XOR m3

How about the affine constant 0x63 we talked about earlier? Turns out that we can omit it.

A vector containing 0x63 in every byte is unchanged by ShiftRows and survives MixColumns because every output row’s coefficients XOR to one:

0x02 XOR 0x03 XOR 0x01 XOR 0x01 = 0x01

Just one final vector XOR restores 0x63.

We can finally AddRoundKey, which is a simple XOR.

To do all this, we only need 15 byte permutations:

Input transformation:          2
Nested inversion:              5
S-Box output and its double:   4
ShiftRows and MixColumns:      4
                              --
Total:                        15

Swizzling infinity

The inversion contains denominators that can be zero. So we need some kind of out-of-range selector to represent infinity.

The inverse tables map a zero denominator to 0x80. XORing that with a nibble can produce anything from 0x80 through 0x8f, but these values all represent the same infinity marker: bit 7 is set, while the low nibble doesn’t matter. When one of them selects from the next 16-byte table, the byte permutation returns zero.

And as mentioned previously, different targets treat out-of-range selectors differently.

Primitive	Out-of-range selector behavior
x86 `PSHUFB`	If selector bit 7 is set, the result is zero; otherwise the low nibble selects
AArch64 `TBL`	Every index above 15 returns zero
WebAssembly strict SIMD	Every index above 15 returns zero
WebAssembly relaxed SIMD	`0x10` to `0x7f` may return zero or use the low nibble; `0x80` to `0xff` returns zero

A selector between 0 and 15 or between 0x80 and 0xff produces the same output everywhere, even in WebAssembly.

And the circuit described above only produces selectors in 0x00 through 0x0f or 0x80 through 0x8f. So, we’re safe!

The default WebAssembly “strict” SIMD mode doesn’t map well to x86 instructions, so the generated code is pretty inefficient.

Fortunately, WebAssembly later introduced a relaxed-simd variant of the instruction that marks selectors in the 0x10 through 0x7f range as “don’t-care” values and lowers directly to a CPU instruction.

It’s a little sad that WebAssembly support is fragmented and relaxed SIMD isn’t supported everywhere yet, most notably in Safari. At least server runtimes such as Wasmer, WasmEdge, Wasmtime, and WAVM have supported it by default for a long time. And Safari will eventually catch up.

Is this technique worth it compared to lookup tables and bitslicing? It is. Compared to lookup tables, it guarantees constant-time execution. And compared to bitslicing, it doesn’t require bit-level representation changes and introduces less register pressure.

Most importantly, it’s a very good match for how some new AES-based ciphers such as AEGIS and HiAE operate. And we can finally have ciphers with half-decent performance on WebAssembly rumtimes without the WASI-Crypto extensions.

The best WebAssembly runtime may still be no runtime at all

2026-07-08T00:00:00+02:00

In 2023, I wrote that the best WebAssembly runtime may be no runtime at all.

To summarize: if you already have a WebAssembly module, translating it to C and compiling that C with a normal native compiler can be surprisingly hard to beat.

I expected that argument to get weaker over time, because WebAssembly runtimes keep improving. Their compilers have better register allocators, better lowering, better support for newer WebAssembly instructions, and more deployment polish than a small transpiler can reasonably have.

Then I ran the 2026 benchmark.

The 2026 WebAssembly benchmark has the full table for other runtimes.

And the WebAssembly-to-C path performed very well, but was beaten by new runtimes implementing the “wide arithmetic” WebAssembly proposal.

I was curious to see how the WebAssembly-to-C approach would work with if that proposal was implemented.

So, let’s compare:

Wasmer 7.1.0
Wasmtime 46.0.0
WABT wasm2c

For wasm2c, I added support for wide arithmetic, which was surprisingly trivial to implement. You can find my fork here.

The generated C code simply uses compiler carry intrinsics and C’s 128-bit integer type.

Note that I compiled the generated C with WABT’s Segue memory mode enabled, with zig cc -O3 -march=native, on the exact same libsodium benchmark suite as the previous runtime post.

Every build uses the lime1+simd128+wide_arithmetic feature set.

Oh, and before you ask: wasm2c supports memory protection using guard pages, like other runtimes.

The speed numbers

The numbers below are slowdowns relative to the native libsodium build. A value of 1.25x native means the benchmark took 25% more time than native code.

Lower is better.

The median is a tie with Wasmer. But the wasm2c executable used 0.887x as much time as Wasmer on the geomean, and 0.814x as much as Wasmtime.

The dumb C path survived the feature upgrade. Once the new arithmetic instructions were added, a normal C compiler could again produce code competitive with dedicated WebAssembly compilers.

Memory usage

I also measured peak resident set size with /usr/bin/time -v.

This is cold process RSS for one command invocation, using the median of fifteen runs. It includes the runtime executable, its startup state, JIT or compilation machinery used by that command, and anything else the process maps while running the benchmark.

Note that Wasmer and Wasmtime have a fixed cost that can be amortized if a service keeps the runtime alive and runs many modules or many calls.

Most of that difference is fixed engine overhead. The module itself costs very little.

If I subtract the RSS of an empty WASI module run through the same path, with a 64 MiB maximum linear memory like the benchmark build, only a couple of MiB remain:

At run time, with the WebAssembly code directly compiled to C, then to executable code, there’s no engine process to bring along.

No runtime is still a good choice

The generated output is portable C.

So, the deployment target no longer has to be “a platform with a WebAssembly runtime”. It can be any platform with a C compiler and enough libc support for whatever the module imports.

It also means the compiler is a choice.

You can compile the generated C with clang or gcc.

But you can also take advantage of modern C toolchains such as Fil-C to get memory safety on wasm64, or on wasm32 without depending on virtual-memory guard pages.

Or you can use a formally verified compiler such as CompCert for high assurance code generation.

I didn’t benchmark those toolchains. The point is that WebAssembly-to-C gives you that option, while a dedicated runtime doesn’t.

This is also why I remain impressed by Wasmer.

Wasmer also implements WASIX, which fills many of the POSIX-shaped gaps that plain WASI still leaves open. So, if your goal is to run existing applications in WebAssembly with fewer rewrites, this is the way to go, not WebAssembly-to-C or other options.

And Wasmtime implements the “Component Model”, that improves code separation and gives applications a typed interface boundary for composing pieces of WebAssembly. I have an intuition that the same thing can be achieved using WebAssembly-to-C by compiling components separately, but I didn’t think about it much.

Regardless WebAssembly-to-C is the wrong answer if you need dynamic loading of untrusted code without precompilation, runtime-level policy, preemption, fuel, component-model machinery, or one engine reused across many tenants.

It’s also the wrong answer if your deployment model depends on shipping one portable .wasm artifact and letting the destination machine choose how to run it.

But if you control the WebAssembly module, can precompile it, and don’t need runtime services, WebAssembly-to-C is very close to a no-brainer, especially with the addition of wide arithmetic.

Performance of WebAssembly runtimes in 2026

2026-06-23T00:00:00+02:00

I wanted to know if WebAssembly runtimes are getting faster.

This is a follow-up to the earlier libsodium WebAssembly benchmarks from 2019, 2021 and 2023.

Not “does the newest version beat native code in one microbenchmark?”, and not “which runtime has the prettiest benchmark chart?”, but something more boring and more useful:

If I take the same C crypto code, compile it to WebAssembly, and run it on the latest runtime, a runtime from one year ago, and a runtime from two years ago, are things actually improving?

So I benchmarked libsodium on WebAssembly runtimes released around June 2024, June 2025, and June 2026.

The short version:

wasmer is the best performer, but WAVM, WAMR and Wasmtime are close.
WAVM has the best optimizer, and is able to generate very fast code out from baseline, portable WebAssembly
The new WebAssembly wide_arithmetic instructions are a big deal for crypto code when runtimes support them.

What I measured

The test program is libsodium’s benchmark suite, built from libsodium commit 8e3be8615ba6adcd7babaecf5e76f516890ba5fb.

I built one native baseline and several WebAssembly variants:

native x86-64, compiled with Zig using the local CPU target
plain WebAssembly
WebAssembly with lime1
WebAssembly with lime1 and simd128
WebAssembly with lime1, simd128, and wide_arithmetic

For the native reference, libsodium was built with -Dcpu=native. For wasm2c, the generated C was compiled with zig cc -O3 -march=native.

For WAMR, I used AOT mode: wamrc compiled each .wasm file to an .aot file, and iwasm ran the resulting AOT file. wamrc doesn’t accept --cpu=native, so I used --target=x86_64 --cpu=x86-64-v4 --opt-level=3, which matches the host’s available x86-64 feature level and works across the WAMR versions that could compile these modules.

The native command was:

zig build -Denable_benchmarks -Doptimize=ReleaseFast -Dcpu=native -Diterations=3

The WebAssembly commands were the same shape, with a wasm32-wasi target and the feature-specific CPU strings:

zig build -Denable_benchmarks -Dtarget=wasm32-wasi -Doptimize=ReleaseFast -Diterations=3
zig build -Denable_benchmarks -Dtarget=wasm32-wasi -Doptimize=ReleaseFast -Dcpu=lime1 -Diterations=3
zig build -Denable_benchmarks -Dtarget=wasm32-wasi -Doptimize=ReleaseFast -Dcpu=lime1+simd128 -Diterations=3
zig build -Denable_benchmarks -Dtarget=wasm32-wasi -Doptimize=ReleaseFast -Dcpu=lime1+simd128+wide_arithmetic -Diterations=3

The host was an AMD Ryzen AI 9 HX 470 with 12 cores and 24 threads. CPU boost was disabled and the maximum CPU frequency was 2 GHz. The OS was Linux 7.1.0-rc7, and Zig was 0.17.0-dev.948+e949341b7.

The numbers below are the geometric mean of per-benchmark slowdowns relative to the native build. Lower is better. A value of 2.0 means “twice as slow as native” on this machine.

I used ITERATIONS=3, so the very small libsodium tests are noisy and quantized. Rows reporting zero time were excluded from the aggregate.

Versions

For every runtime except WAVM, I used the latest stable release available on June 23, 2026, plus a stable release from roughly one year earlier and one from roughly two years earlier.

Runtime	2024	2025	2026
`Bun`	`1.1.16`	`1.2.17`	`1.3.14`
`Node`	`22.3.0`	`24.2.0`	`26.3.1`
`WAMR`	`2.1.0`	`2.3.1`	`2.4.4`
`WABT wasm2c`	`1.0.35`	`1.0.37`	`1.0.41`
`WasmEdge`	`0.14.0`	`0.14.1`	`0.17.0`
`Wasmer`	`4.3.2`	`6.0.1`	`7.1.0`
`Wasmtime`	`22.0.0`	`34.0.0`	`46.0.0`
`WAVM`	`n/a`	`n/a`	`nightly/2026-04-05`
`Wazero`	`1.7.3`	`1.9.0`	`1.12.0`

WAVM is awkward to compare historically. The old available nightly collapsed to a 2022 binary for both the 2024 and 2025 slots, and that binary refused to run on this machine. I only kept the 2026 nightly.

WAMR 2.1.0, the selected 2024 release, installed fine but its AOT compiler failed on these Zig-generated modules with invalid WASM stack data type. I kept the version in the matrix, but didn’t include an aggregate for it.

Baseline WebAssembly

This is the plain WebAssembly build, without lime1, SIMD, or wide arithmetic.

There isn’t one universal trend.

Wasmtime steadily improved: 2.67x native in 2024, 2.54x in 2025, 2.41x in 2026. It got faster every year, and the gains land in the tenths place, above the noise.

Node also improved slowly, from 8.60x native to 7.95x native.

Wazero was basically flat: 4.84x, 4.70x, 4.72x native. No real movement over two years.

WAMR in AOT mode was already fast in 2025 and stayed there in 2026: 1.59x native, then 1.57x native, the same within this benchmark’s noise. I don’t have a complete 2024 WAMR number because WAMR 2.1.0 couldn’t compile these modules.

Wasmer regressed in the 2025 release I tested, then recovered in 2026. The 2026 baseline barely beats 2024.

wasm2c improved modestly in 2026. It remains one of the best options if ahead-of-time translation to native C is acceptable for your deployment model.

Bun is the outlier. Its 2024 and 2025 results were far behind, but the 2026 result is about three times faster than the 2025 result. It’s still slower than Node on this benchmark, but the direction is excellent.

WasmEdge is fast too, but its command-line behavior changed enough to matter. My first 0.17.0 run accidentally used interpreter mode for compiled modules and looked catastrophically slow. Running the compiled modules with --run-mode=aot fixed it: the 2026 baseline was 1.74x native, between the 2024 and 2025 baseline results.

Best supported build by year

The baseline table is useful because it compares the same WebAssembly target everywhere.

But if you’re choosing a runtime for your own deployment, you probably care about the fastest build that runtime can actually run.

So for each runtime and year, I also selected the best complete result among the supported builds: baseline, lime1, lime1+simd128, and lime1+simd128+wide_arithmetic.

Looks similar to the previous graph, except for Wasmtime and Wasmer that really benefit from wide_arithmetic.

Ranked by the best supported build, the complete current-year results are:

CPU feature variants

The WebAssembly feature story is more interesting than the year-to-year runtime story.

For the 2026 releases, these were the aggregate slowdowns:

lime1 and simd128 alone aren’t magic here. Sometimes they help, sometimes they hurt, and sometimes the difference is lost in benchmark noise.

wide_arithmetic is different.

Only Wasmtime and Wasmer could run the full wide_arithmetic build among the complete stable rows I tested. WAMR rejected it with unsupported opcode 0xfc13. But when wide_arithmetic worked, it was the biggest speedup in the whole experiment:

Wasmtime 46.0.0: 2.41x native without it, 1.46x native with it.
Wasmer 7.1.0: 2.08x native without it, 1.33x native with it.

That’s the kind of change I like. A lot of libsodium’s expensive operations are arithmetic-heavy. If the WebAssembly ISA can express that arithmetic directly, the runtime has much less work to rediscover what the C compiler already knew.

Failures

Most runs completed cleanly, but not all of them.

Bun 1.2.17 failed box_easy in the baseline build. Bun 1.1.16 failed pwhash_argon2i in the lime1 and lime1+simd128 builds.

Node 22.3.0 originally failed pwhash_argon2i, pwhash_argon2id, and pwhash_scrypt in the baseline, lime1, and lime1+simd128 builds. The failures weren’t fixed by increasing Node’s JavaScript heap or stack settings. They were fixed by giving the Wasm modules an explicit maximum linear memory. With the baseline build, a 1024-page maximum, or 64 MiB, made pwhash_argon2i, pwhash_argon2id, and pwhash_scrypt complete. But pwhash_scrypt failed with 512 pages and segfaulted again at 1536 pages and above, so this appears to be a V8 memory-mode threshold rather than a simple “more memory is better” setting.

WAMR 2.1.0, the 2024 slot, couldn’t compile even the baseline modules in AOT mode. WAMR 2.3.1 and 2.4.4 compiled and ran the baseline, lime1, and lime1+simd128 builds, but not wide_arithmetic.

Those failures were excluded from the aggregate. So were benchmark rows with a zero reported median.

So, are runtimes getting faster?

Some of them are.

Wasmtime is the cleanest yes: it got faster every year in this benchmark, by a little each time.

Node is also a yes, but the slope is gentle.

Bun is a loud yes between 2025 and 2026. It still has a lot of ground to cover for this workload, but the improvement is too large to ignore.

Wazero is mostly flat.

WAMR is also mostly flat between the versions that worked here, but “flat” at about 1.4x to 1.6x native is a very good place to be.

Wasmer is mixed if you only look at the baseline, but the 2026 release supporting wide_arithmetic changes the practical answer for crypto code. With that feature enabled, it was the fastest complete 2026 result I could compare across a normal current release.

wasm2c remains good. If you can translate WebAssembly to C ahead of time and compile it for the host, it’s hard to beat.

WAVM produced the fastest 2026 baseline number, but I don’t have a fair 2024 or 2025 comparison.

WasmEdge remains excellent once it’s forced into AOT mode. The accidental interpreter-mode run was a good reminder that command-line defaults are part of the benchmark, too.

Takeaways

If you run CPU-heavy cryptography in WebAssembly, runtime choice still matters a lot.

The spread between the fastest complete current result and the slowest current result is large: Wasmer with wide_arithmetic was 1.33x native, while current Bun baseline was 8.77x native.

Feature support matters too. The same runtime can move from “pretty good” to “surprisingly close to native” when the WebAssembly module can use better arithmetic instructions.

The comforting part is that the mainstream runtimes aren’t standing still. Wasmtime improved steadily. Bun made a huge jump. Wasmer gained a feature that matters for real crypto workloads. WasmEdge remained fast once the AOT run mode was explicit.

The less comforting part is that WebAssembly performance still isn’t one thing. It depends on the runtime, the release, the enabled WebAssembly features, whether the code goes through WASI from JavaScript, and whether ahead-of-time native compilation is allowed.

So benchmark your actual workload.

But if your workload looks like libsodium, the answer in 2026 is: WebAssembly can be close to native, wide_arithmetic is worth caring about, and yes, some runtimes really are getting faster.