Summary
Editing latency on large documents is high, but there was no reproducible way to measure it. This is a profiling-backed writeup — a harness, a baseline, and where the time goes — plus a leading hypothesis for the next optimization. It is deliberately not a single-cause claim; the dominant contributor is not yet isolated.
Harness
An opt-in InputLatencyProfiler + a Playwright recorder/comparator (devtools/input-latency/) correlate beforeinput → transaction → coalesced render → per-phase layout → DOM paint → next frame via User Timing. Baseline protocol: 1 warm-up + 5 measured runs of 40 chars @ 100 ms across normal / 4×-CPU / layout-off scenarios. Any future optimization is gated by comparing its report against baseline-a.json.
Baseline findings (4× CPU, 482-page fixture, p95)
- input→DOM-paint ≈ 377 ms
- instrumented pipeline phases ≈ 49% of that (largest single phase:
incremental-layout ≈ 82 ms, ~22%)
- residual ≈ 185 ms (~49%) is un-instrumented — input→transaction apply (~50 ms measured) + the
requestAnimationFrame wait before the coalesced render + gaps between named stages
Separately, at normal CPU a warm-cache bold edit spends ~385–550 ms in layoutDocument (full-document pagination) — measurement is reused, pagination is not. (Single-character typing looks cheaper than bold in the baseline; that scenario dependence isn't explained yet.)
Recommended steps
- Instrument
input → transaction → render-scheduled → beginRender to attribute the ~185 ms residual.
- Add sub-phase instrumentation inside
incrementalLayout to isolate layoutDocument's share.
- Then target one behavior — most likely making
layoutDocument incremental so a keystroke re-paginates only affected pages — gated on a material 4× p95 improvement vs baseline-a.json.
Status
Not started. Harness/baseline live on branch codex/input-latency-profiling (happy to open as a PR if useful). Related to #3838 / #3839 area but independent.
Summary
Editing latency on large documents is high, but there was no reproducible way to measure it. This is a profiling-backed writeup — a harness, a baseline, and where the time goes — plus a leading hypothesis for the next optimization. It is deliberately not a single-cause claim; the dominant contributor is not yet isolated.
Harness
An opt-in
InputLatencyProfiler+ a Playwright recorder/comparator (devtools/input-latency/) correlatebeforeinput → transaction → coalesced render → per-phase layout → DOM paint → next framevia User Timing. Baseline protocol: 1 warm-up + 5 measured runs of 40 chars @ 100 ms across normal / 4×-CPU / layout-off scenarios. Any future optimization is gated by comparing its report againstbaseline-a.json.Baseline findings (4× CPU, 482-page fixture, p95)
incremental-layout≈ 82 ms, ~22%)requestAnimationFramewait before the coalesced render + gaps between named stagesSeparately, at normal CPU a warm-cache bold edit spends ~385–550 ms in
layoutDocument(full-document pagination) — measurement is reused, pagination is not. (Single-character typing looks cheaper than bold in the baseline; that scenario dependence isn't explained yet.)Recommended steps
input → transaction → render-scheduled → beginRenderto attribute the ~185 ms residual.incrementalLayoutto isolatelayoutDocument's share.layoutDocumentincremental so a keystroke re-paginates only affected pages — gated on a material 4× p95 improvement vsbaseline-a.json.Status
Not started. Harness/baseline live on branch
codex/input-latency-profiling(happy to open as a PR if useful). Related to #3838 / #3839 area but independent.