Performance

Summary

Read benchmark trends and the release performance gate.

Every push to main runs the benchmark suite once on a shared Linux runner and records the median of three cold samples per metric. The charts below are those records, newest on the right. They show drift across many small commits; a single point is noise, a slope is a finding.

60 pushes recorded, newest 54ac2f2 on 2026-09-25. Each line is the median of three cold samples on a shared Linux runner.

Render to ready
0 ms1110 ms2219 msoldernewest
  • interaction-latency/render_ready_ms124 ms
  • large-stream/render_ready_ms387 ms
  • non-ascii-stream/render_ready_ms127 ms
Key press latency
0 ms80 ms160 msoldernewest
  • interaction-latency/nav_press_median_ms38 ms
  • interaction-latency/nav_press_p95_ms70 ms
  • large-stream/row_step_median_ms102 ms
  • non-ascii-stream/block_step_median_ms34 ms
Parsing
0 ms78 ms156 msoldernewest
  • artifact-parse/plan_parse_ms59 ms
  • artifact-parse/anchor_fuzzy_resolve_ms11 ms
  • artifact-parse/many_files_diff_rows_ms83 ms
  • artifact-parse/large_file_diff_rows_ms105 ms
Daemon
0 ms53 ms106 msoldernewest
  • daemon-roundtrip/session_create_total_ms80 ms
  • daemon-roundtrip/session_get_total_ms28 ms
Retained memory
0 MiB65 MiB130 MiBoldernewest
  • interaction-latency/after_navigation_heap40 MiB
  • large-stream/after_steps_heap98 MiB
  • daemon-roundtrip/after_sessions_heap19 MiB

What the numbers mean

  • Render to ready is the time from mounting the review to the app's ready signal, with the daemon already running. It is the cost of the artifact, not of launching the binary.
  • Key press latency is a caret move timed until the painted frame settles, as the in-process median and p95. It carries a fixed measurement cost of a few milliseconds, so compare the lines, not the absolute values.
  • Parsing batches fast operations so their totals clear the release gate's 5 ms floor; the batch sizes are constant, so the lines are comparable.
  • Retained memory is heap in use after a full collection.

How releases are guarded

The numbers here are informational. The release workflow separately measures the previous published binary against the fresh one on the same runner, interleaved, and refuses to stage a release whose startup or first frame got materially slower: at least 15 percent and 5 milliseconds. A pull request also receives a comment comparing its head against its merge base with the same thresholds, which never blocks a merge. Details live in the repository's benchmarks README.