Wado Performance

Wado Performance

Speed of the compiled guest Wasm (what wasmtime runs), not the native compiler — that is profiling-wado-compiler.

Loop: profile the hot function → read its WIR for what it allocates/copies per iteration → change one thing → A/B both arms in one session, plus the WIR diff of the hot function → keep or revert (§5 says which evidence decides).

Re-profile before choosing a target: the percentages a WEP or an older note quotes predate whatever has landed since.

A speedup lands in the compiler, not in Wado source. Editing .wado files, the stdlib included, is fine as an experiment: an ablation that prices a piece, or a hand-written shape that shows what the optimizer should emit. Shipping such an edit as the speedup is forbidden, unless the user approves it or asks for it. A fast iteration loop on the stdlib is not a reason to make an exception. §2 and §4 say where the fix goes instead.

1. Profile

wado run --profile guest,profile.json,1 prog.wado   # interval 1 short runs, 0 exhaustive
wado test --profile guest,profile.json,1 file.wado  # same, over one file's test blocks
node .claude/skills/wado-performance/scripts/analyze_guest_profile.ts profile.json [--top N]

The script reports self (leaf) and inclusive counts per function; names keep monomorphization detail, so each instantiation is separate. Loop a one-shot hot phase N times so it clears the fixed setup (aim ≥ ~200 samples). Firefox Profiler (profiler.firefox.com) gives a flame graph; perf + --profile jitdump gives instruction-level (store- vs compute-bound), see docs/jitdump-profiling.md.

Dev-profile inflation: a cargo run wado JITs guest code near-release but runs the wasmtime runtime / GC / allocator at dev speed (~4–5× slower), so profiles over-weight allocation/GC frames — read percentages as relative and size any GC or allocation win by its release number, not the dev multiple. A flat-CST rewrite that cut a benchmark ~3× on dev gained ~1.47× on release, because release GC was only ~⅓ of wall-clock to begin with. Pure compute does not inflate, so a compute-bound win carries over intact.

A sample lands at the next epoch check, not where the time went. The guest profiler samples on an epoch deadline and wasmtime checks the epoch at function entries and loop headers, so straight-line code is charged to whichever it reaches next. A derived deserializer's field-dispatch chain reported as 73% self in deserialize_i32 on an 80-field struct, and 19% in deserialize_bool on cbor-twitter — neither function is more than a bounds check and two compares. A hot small leaf is telling you how often it is entered, so go read its caller. The profile ranks candidates; it does not locate them.

A low self-percentage rules out one dataset, not the function. FieldSchema::lookup read 0.71% on json-catalog, whose widest struct is 16 fields. Rewriting that same function cut 44% off cbor-twitter's decode, where User has 40. Profile a per-item cost on the input whose items are widest.

Rule out a super-linear pass before blaming GC — that same inflation makes an algorithmic blow-up read as GC-bound; sweep input size to tell them apart. Faster-than-linear growth is a hypothesis and not a verdict, since a live set can grow that way too, so the WIR is what settles which.

Sweeping a shape dimension is sharper than size, and the one to vary is the one the suspect is indexed by. Decoding 1000 CBOR records, holding that count fixed so no per-record term is left for the growth to be:

Hold everything but the dimension under test — a sweep that varies two answers about neither.

2. Read the WIR — allocations and copies first

wado dump -O2 prog.wado                 # final WIR
wado dump --tir-monomorphized prog.wado # how `?`, for-of, … desugar

Three villains, each a heap alloc or deep copy, and a bug when one lands per element in a loop:

• struct.new / Box<…> — a heap object. for x of &list boxes every element (WasmGC has no interior references, so a by-ref iterator materializes &T as a box). A tuple is a GC struct too, so retyping a two-field struct as [u64, u64] allocates the same. Two things remove the allocation: multivalue on a return the caller destructures, and SROA on a literal whose fields the optimizer can split into locals. A merge point defeats both preconditions, which is a pass to fix rather than a call site to rewrite (below).
• array.new / array.new_default — a fresh GC array (_default zero-fills); watch for one per call where a buffer could be reused.
• $value_copy$T… — a value-semantics deep copy of a value-typed binding/arg unless the source is fresh (a call / literal / variant result, or a fresh value's payload). x? desugars to match f() {…}, so freshness must see through the match; a missed copy shows up here and is removable.

Count the copies, not only the time: a cut count is a result even when the benchmark is flat. The entry package's copies are its remarks:

wado compile -O2 --log-level info prog.wado 2>&1 | grep -c 'remark: a copy of'

Remarks skip the stdlib, so read a stdlib copy off wado dump -O2.

Moving a copy from a callee into its call sites multiplies it by the number of sites.

Also: a Trait::method(…) call left in a hot loop (the inliner declined it), and array_set_u8 / array_get_value (bounds-checked; one per element is the store floor for Array<T>-backed String / List).

A stdlib workaround is a bug report about a pass

An optimizer fix reaches every Wado program. The stdlib edit that routes around one reaches a single call site, and hides the gap that produced it. So when the shape you are about to rewrite by hand is one a pass exists for, name the pass and read its precondition first. That is where the fix belongs.

Three turned up this way while cutting fts. All three are also live in short, the path every ${x} on a float takes, which is why fixing the first paid on a benchmark fts never touched.

• sroa matches only a direct literal binding. An inlined get_pow10 left let pm = <block with two exits>, one building the struct and one calling out for it, with pm.hi / pm.lo the only uses. The PmHiLo was a heap object per conversion. Fixed by extending slot_temp_sroa, which already scalarized the [tag, slots…] shape, to a struct literal and to an exit that hands over the aggregate: json-canada de +12.7%, ser +7.2%, and uscale_pow10 deleted.
• multi_value_return is all-or-nothing per callee. It wants every call site to be let $tmp = Call(f) whose only uses are field accesses. mul_pow10 had seven sites and six were exactly that; the one yielding the call as a block value disqualified all seven. Fixing the first gap retired this one, since the offending site is now a let. The precondition is unchanged, so the next callee to hit it pays the same way.
• cold_outline refuses a region containing a return (control_escapes), which is every rare slow path there is. Leaving fixed_width_for_prec's out-of-range tail inline cost json-canada ser 6.5% against a byte-identical serialize path: growing a hot function moves everything downstream of it in the module. Hand-splitting it into a function restored the row, and fixed_width_out_of_range in fpfmt.wado is that split.

3. WasmGC cost facts

• The live set is the cost, not the allocation count. The copying collector traces what survives a cycle; an object that dies before the next one is never copied, however many there were. Cutting transient allocations therefore moves nothing — a compiler pass that removed thousands of per-token Box<i32> allocs measured within noise under copying (and −0.7 ms/iter under null). Chase the footprint, not the volume. The same rule retires "iterate by index to stop for x of &list boxing": the boxes die immediately.
• Module-lifetime GC data is a tax on every collection. A decoded table held in a global as one List<i32> per state (~7.4K permanently live objects) made identical hot-function wasm run 3–6× slower purely from the resident graph; flattening it to offset/count columns fixed it. A resident 160 KB flat List<i32> costs ~+0.9 ms/parse, the 7,400-list shape ~+2.4 ms. Prefer flat columns over nested lists, and don't build what nothing reads. Measure the GC share with --collector null (it leaks, so drive a fixed iteration count) vs --collector copying.
• The GC heap's size is part of the measurement. wado starts every guest with 256 MiB (--gc-heap-initial), which the copying collector splits in two, so a benchmark allocates through half a heap rather than climbing to one. A raw wasmtime invocation starts at zero and doubles its way up to the working set, paying a full trace at every rung — and there the ranking of two compilers flips with the heap size rather than with the code. Even a fixed size is one sample: a change that allocates less moves where the collections land, and gale-gen read 4% slower at 512m where the sweep's geometric mean read it faster. On an allocation-heavy row, sweep --gc-heap-initial and compare geometric means (dead-ends.md).
• with_capacity zero-fills. List::with_capacity(n) is an array.new_default, so an over-sized arena pays for every slot it never uses — once badly enough to turn a 2× faster build into a 4× slower one. Growing from [] by doubling is not the fix either: it zero-fills ~2.4× more than a reasonable pre-size. Size it about right, or grow.
• GC-array access is bounds-checked, no unchecked variant. A lookup table in a GC array adds a checked load per access — it lost to plain arithmetic.
• A lone array.get costs ~20 machine instructions; gets sharing a block cost ~8. wasmtime re-derives the object's null check, its length load and the overflow-checked element address per get, and neither hoists them out of a loop nor shares them across blocks — only across gets in one block. Read the actual sequence with wasmtime explore -W gc,function-references f.wat; a byte-at-a-time loop is 22 instructions and 6 branches per byte, four gets in one block are 18 + 4×8. So a scan reads several bytes per bounds check and then tests them: peek_after_whitespace_run in core:json is that shape, worth 12.6% on json-catalog deserialize. It pays in proportion to the run it covers, against the one partial block it always wastes — under ~16 bytes per run it is a loss. Four is where the sharing stops: a wider block only adds lone gets, and measures worse the wider it gets (dead-ends.md). array.set shares nothing: a store may write the header as far as Cranelift knows, so four adjacent sets reload the length four times. Only array.copy / array.fill amortise a write.
• SROA is priced by the aggregate's width, not by the allocation it removes. Splitting a 40-slot tuple into locals deletes one struct.new per struct and costs 6.5% on cbor-twitter: past the register file, forty ref locals live across a call-heavy loop are forty spill slots reloaded at every call boundary, plus a ref.null init apiece at entry. "The allocation is gone" says nothing about which side won (dead-ends.md).
• array.copy is fast; leave it alone. It beats a hand-written loop from a couple of bytes on — the loop pays the bounds check above on both the get and the set of every byte. Neither hand-roll it nor contort an algorithm to avoid it (dead-ends.md). Its length decides the cost: a constant one compiles to inline loads and stores, a run-time one calls wasmtime_builtin_memory_copy. So a small copy repeated per item pays to reach the copy with a constant length, which is what param_spec cloning on name.used gave the JSON key writer.
• Constant / and % are cheap (Cranelift magic-multiply, x/k and x%k fused) — don't trade a divide for extra multiplies.
• A short compare cascade is not a dispatch problem. Cranelift lowers a short else if chain competitively, and a match over it (a br_table) adds an indirect branch: two separate rewrites to jump tables measured flat and slightly slower. Such a frame is usually call-frequency-bound, not dispatch-bound — cut the calls, not the branch. What does answer to dispatch is a cascade long enough to pay for that branch, or one that is not a cascade at all: independent ifs no arm leaves test every key whatever matched, which nir/if_chain_to_match is what fixes. A set membership test, k matches { A | B | 'x'..='z' | … }, is neither. match_to_bitset lowers it to a branch-free mask test when the scrutinee is 32 bits or narrower and the members span at most 256 values, so write it as the set rather than hand-rolling a range compare or a table. Past that span it is a br_table.
• Write into the caller's buffer, not a temp. `{v}` allocates a throwaway String and copies it in, per value; buf.push_display(&v) skips both. A run of adjacent push / push_str calls is fused into one capacity check by nir/string_push, so write the appends plainly and let it batch them.
• internal_raw_data() / returning Array<T> by value is a copy API — for a single read use get_unchecked / set_byte_unchecked.
• An assert of a caller-guaranteed precondition is free; the same test as a guard is not. is_json_ws in core:json needs b < 64 (Wasm masks a shift count mod 64) and every call site short-circuits on b > b' ' first. Writing the precondition as assert b < 64 measures flat on json-catalog deserialize; writing it as b < 64 && in the returned expression costs 6%, and dropping the bitset for four compares costs 19%. So a hot leaf whose precondition the callers establish keeps both the assert and the fast body. Measure the assert and the guard as separate arms: folded into one they read as a single cost, and the assert takes the blame for what the guard spent.

4. Inlining: fix the inliner, never the code

An inline hint or a hand-inlined body is almost never worth it: it reaches one call site, and it silently outlives the measurement that justified it. The stdlib carries no #[inline] / #[inline(never)], because a hint that makes code faster marks a case the optimizer misses.

Improving the inliner is what pays, and it keeps being improved. A better price reaches every program at once. When it declines a callee that should be spliced, that is a cost-model bug: find the price with WADO_TRACE=inline and fix it in optimize/inline.rs.

Never bend source to the inliner's current prices. Collapsing lets into one expression, choosing an operation width, or splitting a function only to get under the threshold are all banned. It is §2's rule applied to the inliner: the contortion reaches one call site and hides the gap from every other. zlib's read_u32_le is the case that set this rule. Widening each byte to u64 priced it one instruction over the threshold, and doing the arithmetic in u32 with one widening at the end got it inlined. But the widening costs nothing: Cranelift folds an i64.extend_i32_u into the load or arithmetic producing it. The price was wrong, and is_zero_extension in optimize/inline.rs is its fix.

Raising the threshold wholesale is not the lever: it bloats hot loops and measured slower. The lever is a price that matches what the spliced code costs.

A split that is right on its own stays. A slow path that is not rare is one: a width > 0 branch runs every time a width is set, so it is hot when taken and no cold_path() marker should claim otherwise. A rare heavy sub-case needs no hand-split at all: nir/cold_outline moves what the marker opens into a function of its own, so the leaf inlines at its hot-path size. A marker cold_outline cannot take (mid-loop-body, see that pass's module doc) is a gap in that pass, per §2.