Field Notes/Runtime/Dispatch 023
APR 18 · 2026·9 MIN READ·DISPATCH 023

Cold-start is a feature: 142 ms to first frame on a Pixel 6.

Cold-start was the line we could not cross. Here is the pass-by-pass account of how we got the runtime to first frame in 142 milliseconds.

Kenji ParkRuntime engineer · KetoyVM
FIG 00 · KETOY FIELD · 142 MS

For a year, cold-start was the number that kept us honest. Every other benchmark could be tuned in isolation. Cold-start collapsed the whole runtime into one observable.

We measured the path from KetoyRuntime.load() to the first recomposition finishing. No network. Local bundle, cached on disk. A 142-composable tree. Pixel 6, AOSP 15. This post is an accounting of how that number moved.

§ 01 — BASELINE910 ms, mostly in verification

Our first honest measurement was 910 ms. The bulk of it was verifier overhead. We were running an over-general dataflow pass because we had inherited JVM-style invariants that KBC had already retired.

The fastest verifier is the one that proves the fewest theorems.
Pinned above the runtime team desk

§ 02 — THE WINSWhat actually moved the number

NOTE

The single largest win was moving verification out of the critical path. It now runs in parallel with disk read for the next section, so by the time we are ready to link, verification is done.

That took us to 142 ms. On a cold device cache, with no tricks. The floor, we think, is somewhere near 90 ms, bounded by IO and the native Compose layout pass. We are not there yet.


— K.P. · Runtime, Apr 18 2026