Say why a run is slow: per-stage timing, and a JIT check

[adulbrich]

The deployed site ran the reference bracket in 6m32s against 30s for the same build served locally, in the same browser on the same machine. This PR is what found the cause, plus the check that stops it happening to anyone else.

The cause

Microsoft Edge's "Enhance your security on the web" disables the JavaScript JIT for sites it does not consider familiar, and a freshly deployed URL never is. Everything then runs interpreted, WebAssembly included. localhost was unaffected because a site you open every day stays on that feature's allowlist — which is precisely what makes it read as "the deployment is slow".

Confirmed by disabling the setting: full speed returns.

Nothing was wrong with the deployment, the WebAssembly build, the worker, or #260.

Why this needed instrumentation

Four explanations were argued from wall-clock timestamps before anything was measured, and every one was wrong:

hypothesis	killed by
hdrgen is slow	merges this bracket at native speed (#261)
the wasm download	4.0 MB total; a 4m29s merge needs ~10 KB/s
compilation	hdrgen compiles in 3 ms
DevTools attached	tested; no change

The first instrumented run ended it in one reading:

Filtering images: kept 13 of 18 in 23.6s
hdrgen took 248.5s: fetch+compile 0.9s, instantiate 0.0s, stage 0.0s, run 247.5s, collect 0.0s

Fetch and compile under a second; execution the entire loss. And the filter stage — which runs no WebAssembly at all — was slow too, which pointed away from wasm entirely. A pure-JS loop then settled it: 2736 ms on the deployed tab against 247 ms locally, on a fresh tab with nothing loaded.

What this adds

Per-tool timing. Each invocation is timed in six parts (fetch/evaluate glue, fetch/compile wasm, instantiate, stage, callMain, collect) and reports itself only when its total passes one second. A healthy run stays silent, so any line at all is worth reading. This is what distinguishes a hosting problem from a build problem, and it cannot be recovered from timestamps afterwards.

The filter stage reports its own duration. It runs no WebAssembly, so whether it slows down alongside everything else separates "wasm is slow" from "everything is slow".

A JIT check at the start of each run. A ~30 ms arithmetic loop; if the engine is far below what a working JIT delivers, the run console says so and names the setting. The threshold errs towards firing: nothing in JavaScript distinguishes a disabled JIT from a slow device, and the message is true either way, so it reports what was measured and offers the usual cause rather than asserting it. 32 ms with a JIT here, 271 ms without.

DEPLOYMENT.md records the whole thing under known limits.

Verification

431 tests, tsc clean, lint clean, full 18-frame browser pipeline passing end to end in 32.6s with all of it in place. The calibration loop costs 32 ms against a run measured in tens of seconds.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
lumilab	Ready	Preview	Aug 7, 2026 9:11am

[adulbrich]

This instrumentation did its job on the first run, so recording the outcome here.

The deployed-site log with it enabled:

Filtering images: kept 13 of 18 in 23.6s
hdrgen took 248.5s: fetch+compile 0.9s, instantiate 0.0s, stage 0.0s, run 247.5s, collect 0.0s
ra_xyze took 13.6s: fetch+compile 0.5s, ..., run 13.0s
evalglare took 15.1s: fetch+compile 0.5s, ..., run 14.6s

Fetch and compile cost under a second per module and zero once cached. Execution is the entire loss. That ruled out delivery, Content-Type, cache headers, the serial waterfall, buffer copying, instantiation and worker reuse in one reading, none of which could be separated from wall-clock timestamps before.

The Filtering images … in 23.6s line was the one that pointed away from WebAssembly altogether: that stage runs none, only createImageBitmap per frame, and it was slow too.

A pure-JavaScript loop with no network and no wasm then settled it:

tab	ms
deployed	2712
local	247

11x, matching the pipeline's ratios. The tab was getting a fraction of the CPU; the deployment, the WebAssembly build and #260 are all exonerated.

Worth merging on its own merits: four hypotheses were argued from wall-clock timestamps before this existed and every one of them was wrong.