Lobsters benchmark results

1. Roundhouse vs Rails — runtime × JIT

3.69× faster than Rails — 133.6 ms/iter vs Rails' 493.2, both stacks CRuby with YJIT. The full field:

Every lane replays the same frozen sequence in-process, in-memory, single-threaded — no HTTP server, no load generator — so the only variable across rows is the interpreter × JIT under test (the ruby-bench lobsters-for-YJIT shape). Lower is better; whiskers span each lane's min–max.

• Rails gains 1.68× from YJIT (827.0 → 493.2 ms/iter)
• Roundhouse gains 1.33× from YJIT (177.2 → 133.6 ms/iter)
• Roundhouse is 3.69× faster than Rails with YJIT (493.2 → 133.6 ms/iter)
• Roundhouse is 4.67× faster than Rails without a JIT (827.0 → 177.2 ms/iter)

Drifting lanes: Roundhouse YJIT slowed 10.4% between the first and last quarter of its own timed iterations; Roundhouse no JIT sped up 7.2% between the first and last quarter of its own timed iterations. A drifting lane's median depends on how long the run was, so its ratio is not a stable number — read it as a range, not a point. Lanes that hold steady drift under 1%.

“vs Rails” is a speed ratio — Rails' ms/iter ÷ this row's, at the same JIT level — so 3× means three times faster. Memory is a separate section below. CV = per-lane standard deviation ÷ mean across the timed iterations.

Lanes measured 2026-07-30T15:38:56Z · host showcase.party — one process per lane, JIT pinned per lane.

2. Per-endpoint breakdown

Where the overall 3.69× win comes from — each endpoint's median latency over every timed visit of the frozen sequence, per lane. Bars are log-scaled; the ratio at the right is Rails ÷ roundhouse (both CRuby +YJIT) (green = roundhouse faster). The chart draws rails, roundhouse, roundhouse AOT; the no-JIT lanes appear as extra columns in the table below.

A diagnostic breakdown, not a re-derivation: per-endpoint medians don't sum to the sequence median (GC and ordering don't decompose linearly), and the sub-millisecond rows sit near clock resolution — trust the ranking, not the third decimal.

3. Memory footprint

Peak resident memory of each lane's replay process — lower is better. Because the lanes replay in-process, each one measures itself (VmHWM from /proc/self/status), so this is the whole stack: interpreter, framework, the in-memory fixture DB, and whatever the timed run retains on top.

The bar splits at the point the sequence starts. The solid segment is the baseline — everything loaded and seeded, before a single visit. The translucent segment is growth across the timed run. The two say different things: baseline is what the stack costs to stand up, growth is what serving retains.

• Rails pays 38 MB (+13%) in peak memory for YJIT, buying 1.68× the speed
• Roundhouse pays 20 MB (+20%) in peak memory for YJIT, buying 1.33× the speed
• Roundhouse peaks 2.81× lower than Rails with YJIT (344 → 122 MB), and starts 2.11× lower before serving anything (183 → 87 MB)
• Roundhouse peaks 3.00× lower than Rails without a JIT (305 → 102 MB), and starts 2.06× lower before serving anything (175 → 85 MB)
• Across the timed run Rails retains 4.5× more than Roundhouse (161 MB of growth against 36 MB) — a separate fact from the baseline gap, and the one a peak-only number hides

“vs Rails (memory)” is peak RSS ÷ peak RSS at the same JIT level — not the speed ratio in the matrix table above; the two differ. Baseline is sampled after the in-memory fixture DB is seeded, and it is not a common floor across lanes — each stack loads its own framework, so subtracting one lane's baseline from another's peak is meaningless.

4. Coverage & parity (26/26 · spinel 25/26)

Incomplete coverage: 1 route(s) fail on the spinel AOT lane — the failing routes' visits short-circuit cheaply, so treat the affected lane's timing rows above as optimistic. Details in the table.

5. Environment & provenance

Generated 2026-07-30T22:35:23Z from summary.json.