Perf: slice run <dir> re-bundles on every invocation (SvelteKit workload: 160 ms vs Node 117 ms, Deno 70 ms, Bun 56 ms) #63

Test I ran

Timed each command 10 times after 2 warm-ups on tests/frameworks/04-sveltekit-edge-ssr (after bun install and bun run build), wall clock from a Python subprocess.run, median reported.

slice run tests/frameworks/04-sveltekit-edge-ssr            # source mode
slice pack tests/frameworks/04-sveltekit-edge-ssr out.cas
slice run out.cas
node  tests/frameworks/04-sveltekit-edge-ssr/src/index.ts
bun run tests/frameworks/04-sveltekit-edge-ssr/src/index.ts
deno run -A tests/frameworks/04-sveltekit-edge-ssr/src/index.ts

Result (median ms)

slice run <dir> costs about pack + run out.cas every time and is identical on the second batch, so nothing is cached between invocations. I found no cache directory or mtime check in crates/slice-cli/src/commands/run.rs.

Across all 33 workloads in the harness run, source mode is faster than Node on 32, faster than Deno on 28 and faster than Bun on 2; the packed .cas is faster than Node and Deno on 33 and faster than Bun on 25. This SvelteKit workload is the one case where a Slice mode is slower than all three other runtimes.

Suggestion

Cache the packed result of slice run <dir|file> keyed by the content hashes the CAS builder already computes (plus the Slice version), and reuse it when nothing changed. That would bring the edit-run loop close to the .cas number (37 ms here) without asking users to run slice pack by hand.

Environment

• Slice v0.10.7, commit ea7c70c, cargo +1.96.0 build --release --locked
• Node v24.22.2, Bun 1.4.4, Deno 2.9.8; Ubuntu 26.04, Linux 7.0, x86_64, i5-13500H