slice serve: low-concurrency per-request overhead (c=1 is 2.7× slower than Bun) #38

Summary

Under a closed-loop load test with a fresh TCP connection per request, slice serve is competitive at concurrency 8 but noticeably slower at concurrency 1:

Same machine, same Python client, 3 × 1,000 requests each, all 24,000 responses validated. (The in-repo report shows 148k req/s with 8 sockets × 8-deep pipelining and keep-alive — a different regime where connection setup and isolate acquisition are amortised.)

Interpretation

At c=1 each request pays the full path: accept → parse → acquire warm isolate from pool → run → release. ~0.25 ms of fixed overhead per request versus Bun suggests the per-request isolate acquisition/reset (prelude shard check, VFS/KV snapshot bookkeeping, fuel reset) or the accept path is the cost, not the handler.

Proposal

• Profile a single-request path with --trace and publish the breakdown (accept, parse, acquire, exec, respond).
• Keep a per-worker-thread hot isolate bound for the lifetime of a keep-alive connection instead of acquire/release per request; re-acquire only on tenant change.
• Make isolate reset lazy: snapshot only the state the previous request actually mutated (VFS/KV dirty bits are already tracked for time-travel).
• Consider SO_REUSEPORT + per-worker accept loops to avoid a shared accept lock at low concurrency.
• Add a c=1 fresh-connection case to tests/reports so this regime is tracked alongside the pipelined one.