cueloop

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 6d896d6 on 2026-10-07. Each line is the median of three cold samples on a shared Linux runner.

Render to ready
0 ms340 ms679 msoldernewest
  • interaction-latency/render_ready_ms81 ms
  • large-stream/render_ready_ms354 ms
  • non-ascii-stream/render_ready_ms80 ms
Key press latency
0 ms79 ms158 msoldernewest
  • interaction-latency/nav_press_median_ms31 ms
  • interaction-latency/nav_press_p95_ms54 ms
  • large-stream/row_step_median_ms79 ms
  • non-ascii-stream/block_step_median_ms26 ms
Parsing
0 ms68 ms136 msoldernewest
  • artifact-parse/plan_parse_ms39 ms
  • artifact-parse/anchor_fuzzy_resolve_ms7 ms
  • artifact-parse/many_files_diff_rows_ms60 ms
  • artifact-parse/large_file_diff_rows_ms71 ms
Daemon
0 ms50 ms101 msoldernewest
  • daemon-roundtrip/session_create_total_ms47 ms
  • daemon-roundtrip/session_get_total_ms14 ms
Retained memory
0 MiB59 MiB118 MiBoldernewest
  • interaction-latency/after_navigation_heap38 MiB
  • large-stream/after_steps_heap104 MiB
  • daemon-roundtrip/after_sessions_heap18 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.