perf: startup time investigation — proposal to close the gap with Node/Deno

[sonukapoor]

I've been investigating Edge's cold-start performance on the startup-investigation branch and wanted to share findings and get your thoughts on direction before going further.

What I measured

Using hyperfine --warmup 10 --runs 80 on frozen binaries:

Command	Edge (current)	Node.js	Deno	Bun
eval ""	~41ms	~40–50ms	~20–35ms	~5–12ms

Edge is already in range with Node. The gap to Deno is real and closeable. Bun is a different engine (JavaScriptCore) so that gap is architectural.

Root cause

The startup path was instrumented with EDGE_STARTUP_TRACE=1 and finer per-bootstrapper timing. The picture is clear:

• ~19ms total is spent executing bootstrap JS on every cold start
• ~8ms of that is bootstrap/node.js alone
• No V8 startup snapshot exists — V8 parses and compiles all bootstrap JS fresh on every process launch
• Micro-deferral experiments (lazy-loading individual modules) were tried and repeatedly reverted: they shift cost between trace buckets but don't eliminate it

The pre-JS host-side costs (OpenSSL init ~0.7ms, N-API env creation ~1.2ms) are comparatively small. The real leverage is the 19ms of repeated JS compilation.

Two options I'd like your input on

Option A — V8 bytecode cache (lower risk, faster to ship)

Precompile all bootstrap JS to V8 bytecode at build time and embed alongside the source. On startup, V8 deserializes instead of parsing and compiling. Skips the majority of per-module compile overhead.

• Estimated win: ~8–12ms off cold start
• Effort: a few days
• Risk: low — graceful fallback to source if cache is invalid

Option B — V8 startup snapshot (larger win, more involved)

After running all bootstrap JS during a dedicated build step, serialize the V8 heap. Embed the blob in the binary. On startup, deserialize instead of executing any bootstrap JS at all. This is what Node.js and Deno do.

• Estimated win: ~15–18ms off cold start
• Effort: a few weeks
• Risk: medium — requires identifying which bootstrap code is snapshot-safe, build pipeline changes

What's already landed on this branch

Three small wins are already in place:

• BuildEffectiveCliState() skips cwd resolution when no --env-file/--experimental-config-file flags are present (~1.7% improvement on -e "")
• Report binding creation deferred to first use
• Native --help fast path

My ask

@syrusakbary

I'd like to own this area. Before going further I wanted to check:

1. Does this direction (closing the startup gap with Deno) align with your priorities?
2. Between Option A and B — which scope feels right?
3. Any constraints I should be aware of (build pipeline, snapshot safety requirements, platform targets)?

Happy to start with a spike on Option A to get concrete numbers before committing to either approach fully.

[sonukapoor]

@syrusakbary Can you take a look at this PR?

[sonukapoor]

Small update after #67 landed: the merged PR kept the startup tracing/native-path cleanup but left the larger source-map and snapshot direction out, as discussed in review.

I’m treating startup snapshot / bytecode-cache work as a separate design decision rather than starting implementation directly.

@syrusakbary when you get a chance, would you prefer that I:

• open a short design issue for startup snapshot / bytecode-cache options,
• start with a small local prototype to get concrete numbers first,
• or defer this and focus on production-readiness compatibility work from Track skipped Node compatibility tests from CI stabilization #75 for now?

[syrusakbary]

Hey @sonukapoor , I've added support for precompilation in this PR: #97

If you want to check the timings again, that would be great.

[sonukapoor]

I reran the original eval "" startup lane on current main after #97 landed.

Setup:

git fetch upstream
git worktree add .worktrees/precompilation-timings -b benchmark/precompilation-timings upstream/main
cd .worktrees/precompilation-timings
git submodule update --init --recursive
make build JOBS=4
./build-edge/edge -e ""
hyperfine --warmup 10 --runs 80 \
  --command-name "edge default" "./build-edge/edge -e \"\"" \
  --command-name "edge no bytecode cache" "./build-edge/edge --no-bytecode-cache -e \"\"" \
  --command-name node "node -e \"\"" \
  --command-name deno "deno eval \"\"" \
  --command-name bun "bun -e \"\""

Head tested: upstream/main at 20bd0b83 (./build-edge/edge --version reports v24.13.2-pre, process.versions.edge reports 0.0.0-20bd0b8).

Local macOS arm64 results:

command	mean
./build-edge/edge -e ""	31.6 ms +/- 3.2
./build-edge/edge --no-bytecode-cache -e ""	39.3 ms +/- 3.7
node -e ""	21.7 ms +/- 1.6
deno eval ""	210.3 ms +/- 6.9
bun -e ""	2.7 ms +/- 0.4

The most direct comparison for #97 is Edge default vs --no-bytecode-cache: on this machine the builtins cache reduces the original -e "" startup lane by about 7.7 ms, from 39.3 ms to 31.6 ms. That is in the range I expected for the lower-risk bytecode-cache direction in the original issue.

I would be careful with the runtime comparator row here because my local comparator versions differ from the earlier issue snapshot, and the Deno result is not comparable to the earlier 20-35 ms range. The useful signal is the Edge-internal before/after with and without bytecode cache on the same binary.

As a secondary check, I also ran the #97 bytecode-cache benchmark script with WARMUP=10 RUNS=40. That confirms the broader precompilation behavior, but those CJS/ESM lanes intentionally make parse/compile cost dominant, so I would treat them as supporting evidence rather than the headline for this startup issue:

engine / lane	cold / disabled	warm precompiled/cache	cold -> warm
V8 / CJS	102.4 ms +/- 0.6	60.1 ms +/- 1.4	1.70x
V8 / ESM	100.9 ms +/- 0.9	63.3 ms +/- 0.9	1.59x
V8 / builtins-empty	40.7 ms +/- 0.8	30.9 ms +/- 0.5	1.32x
QuickJS / CJS	195.6 ms +/- 1.3	91.5 ms +/- 3.0	2.14x
QuickJS / ESM	210.3 ms +/- 2.2	115.5 ms +/- 3.6	1.82x
QuickJS / builtins-empty	60.3 ms +/- 0.7	33.6 ms +/- 1.4	1.80x

So my read is: #97 materially improves the exact -e "" startup path from this issue, but it does not change the larger snapshot question. Bytecode cache removes a meaningful chunk of repeated compile work; a startup snapshot would still be the next mechanism if we want to avoid more of the bootstrap execution path itself.