Hot-loop JS performance: JSON×10k is 14.8× slower than Bun in a warm isolate #37

Summary

Process startup and memory are now consistently strong (v0.10.5 beats Node and Deno on all 22 validated apps, Bun on 17/22, 10.9 MiB RSS vs Bun 16.7 MiB). The remaining performance gap is steady-state JavaScript execution inside a warm isolate:

That is 14.8× slower than Bun on JSON (down from 30.9× in 0.9.9 — the monomorphic inline caches in the vendored Boa clearly helped) and 7.6× on numeric code that numeric_vm does not catch.

Why it matters

Slice's target workloads (per-request handlers, agent tool calls, tenant automations) are short — but "short" still includes parsing a 200 KB JSON body, running a template engine, or validating a schema with zod. At 15× those become the dominant cost and erase the startup advantage after a handful of requests.

Proposal — in order of cost/benefit

1. Polymorphic inline caches (2–4 entry) for property get/set and method calls; the current IC is monomorphic (get_fast).
2. Shape/hidden-class transitions with a transition tree so object literals built in a loop share shapes; most JSON-heavy code benefits immediately.
3. Fast paths in JSON.parse/JSON.stringify operating on the shape table directly (the streaming JsonSeed parser is a start; stringify still walks generic property enumeration).
4. Baseline JIT for hot CodeBlocks via cranelift — a 1:1 bytecode→machine-code translation without speculation keeps the attack surface small, keeps fuel metering exact (emit a counter decrement per basic block), and historically gives 2–5× over a bytecode interpreter.
5. Publish a benchmarks/hot-loop/ micro-suite in CI so each of the above has a visible before/after.

Alternatively, document the trade-off explicitly: Slice is an interpreter by design (determinism, metering, memory safety) and hot-loop performance will stay in the interpreter class.