[AnthonyRonning]

Every streamed chunk made the chat add up the size of every loaded row, copying each row's id on the way. A chunk now costs about a tenth as much in a long task (59.5 µs → 5.6 µs at 2,000 rows). This is the first fix from the UI performance audit (code-docs#123, item 2).

Cause

The transcript keeps at most 2,000 rows and 32 MiB loaded. apply_timeline_item enforces that after every event by calling bound_transcript_window, which summed the weight of every loaded row and cloned each row's id to look its weight up. So one chunk cost more the more rows were loaded, and a queued batch of 256 chunks paid that 256 times in one UI-thread update.

With application Vim on, follow_application_stream did similar work a second time: it collected the id of every row to read the last one.

What changes

• The window keeps a running byte total. RowWeights holds each loaded row's weight and their sum. A row that arrives or changes adjusts the sum (bound_after_row_change). A bulk change, such as a page of history or another task, still weighs every row (bound_transcript_window, as before).
• Application Vim looks for the newest row from the end instead of listing every row.

Nothing a user sees changes. The 2,000-row and 32 MiB limits, which rows are dropped and from which end are all as before.

One scan per event remains: the search for the row that carries an event's live identity. It compares without allocating and costs about 2 µs per 1,000 rows, which is the growth left in the "after" column below. Replacing it needs a second index kept in step with the rows, so it is left alone.

Measured

A throwaway probe (not in this PR) built a tool-heavy transcript, applied 2,000 streamed chunks to its last row and timed apply_timeline_item. Release profile, Mac Studio, median of three runs, alternating the two binaries on an idle machine:

Rows loaded	Per chunk, before	Per chunk, after	Batch of 256, before → after
100	4.8 µs	1.4 µs	1.2 ms → 0.35 ms
500	20.4 µs	2.8 µs	5.2 ms → 0.73 ms
1,000	34.4 µs	4.0 µs	8.8 ms → 1.0 ms
1,990	59.5 µs	5.6 µs	15.2 ms → 1.4 ms

With application Vim on, through the whole event path (apply_incoming_item, dev profile): 107.5 µs → 6.4 µs per chunk at 1,990 rows, 30.8 µs → 2.9 µs at 500.

What this is worth: at ordinary transcript sizes a user will not feel the difference. It matters when chunks queue up in a long task, where one full batch held the UI thread for 15 ms (a frame at 60 Hz, two at 120 Hz) and now takes 1.4 ms. A slow batch lets more chunks queue behind it, and a full queue forces the chat to reload, so this is the path where falling behind compounds.

It does not change what a frame costs. The same probe put one redraw of the transcript at 0.14 ms with a 1 KB message on screen and 2.0 ms with a 50 KB one (the test window does not shape text, so the real figures are higher). That is the larger cost and the audit's later items cover it.

Remote

No protocol, capability or host change. A paired computer's chat runs the same code and gets the same saving.

Verification

• just ci passes (format, the four clippy configurations, every test), and the pre-commit lint and test lanes passed on the commit.
• New tests:
  • row_weights_follow_streamed_rekeyed_and_evicted_rows: the running total equals a fresh sum after a bulk load, a row that grows and shrinks, a live row that takes its stored key, and rows pushed out past the 2,000-row cap.
  • a_streamed_row_past_the_byte_budget_evicts_the_oldest_row: a row whose growth takes the window past 32 MiB still drops the oldest row, through the path that no longer rescans.
  • test_application_vim_follows_a_stream_to_its_newest_selectable_row: the Vim row follows each streamed row and skips rows the transcript does not show.
• Not checked in a running app: there is no visible change to look for, and the app has no frame or batch timing to read yet.

🤖 Generated with Claude Code

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}