Scrolling to the top of a synthetic 13,000-item thread takes ~2.4 s of server time: every history page re-reads the whole thread#20427

A fix for the per-page index rebuild is written and measured, on a branch. I have not opened a pull request; I would open one once triage confirms the direction.

Branch: https://github.com/bompus/t3code/tree/perf/history-page-index (one commit, 0e6192fc34, on upstream/main 33aa461478; 4 files, +106/−30).

Change. getThreadHistoryPage and getTimelinePage keep the rebuilt timeline index for the 4 most recently read threads and reuse it while the newest event of the thread and of every thread it forks from is unchanged. The check is the same revision query ThreadFind already uses for its scan cache; it moved into threadRevision.ts so ProjectionStore.ts does not statically import ThreadFind.ts (open #18220 loads that lazily). Threads with no events are never cached. This is the "per-thread timeline-index cache" direction from Diagnosis; I did not try the ordinal-window query.

Results (synthetic thread, as in the evidence above). Before and after were run back to back, 3 runs each, on upstream/main and on the branch.

Limits: the thread is synthetic (assistant messages with a user message every 9 items, 500 characters of filler each), so this measures the index cost and not a mix of item types. The baseline's three runs spread by up to 5.4%. I have not measured it on a real thread or the event-loop gap beside the wall time. The first page after any write to the thread still pays the full rebuild, and a thread that is streaming invalidates its entry on every event, so the gain is for scrolling back through a thread that is not being written to.

Checks. ThreadFind.test.ts, ProjectionStore.test.ts, threadHistoryPaging.test.ts and ThreadSearch.test.ts pass (90 tests), including a new one that reads a timeline while the thread and its fork source gain items and fails if the cache never invalidates. Server typecheck, lint and format are clean on the changed files. The branch merges cleanly with #20104.

Two decisions for whoever reviews it.

• The cache holds 4 threads. That bounds the count, not the bytes; each entry keeps one small descriptor per item of the thread and its fork ancestors. Actual size is unmeasured.
• ProjectionMaintenance.rebuild replays projections without appending events, so a warm cache would not notice it. Nothing in the server calls it today. A comment says a future caller needs a fresh store; clearing the cache from rebuild is the alternative.

Follow-up: I ran the same before/after on real threads, not the synthetic one. The gain is real but smaller.

Setup. A read-only snapshot (VACUUM INTO) of a long-used local statev2.sqlite (14.9 GB), opened on a copy. The three largest threads, 12,291 to 16,809 visible items each. Each run scrolls from the newest window to the top through getThreadHistoryPage, in process (no WebSocket). upstream/main against the branch, back to back, 3 runs each in 2 interleaved rounds (6 runs per arm), medians below. "Longest loop gap" is the largest event-loop delay reported by monitorEventLoopDelay during the scrollback.

Run-to-run spread within an arm was 10 to 15% of its median, so all three are outside it.

Why smaller than the synthetic 12×. A real history page holds many rows (6 to 11 pages cover 12,000 to 17,000 items, about 1,300 to 2,000 rows each), so there are far fewer pages to repeat the index rebuild on, and each page also spends time reading and decoding its own payloads, which the cache does not touch. The synthetic thread has about 75 rows per page and 72 pages. The quadratic term is therefore a much smaller share of a real scrollback than the first numbers suggested; what remains after the fix is mostly per-page payload work (about 45 to 106 ms per page).

Limits: one machine and one user's database, the three largest threads only; the 15 GB file was fully in the OS page cache, so cold-disk behavior is not measured; and this is the server function, not the full path through the WebSocket to a client.

Second finding from the real-data runs: once the index cache removes the rebuild, most of what a history page still costs is decoding stored bytes that the page then throws away. I have a change that skips them, on a branch. No pull request.

Where a page spends its time after the cache. Copy of my own database, the three largest threads (13.7k–17.5k items), scrolling back from the newest window to the top, in process with a warm file cache. Of the remaining scrollback time, 63–75% is decoding the stored payloads and projecting them for the wire; 19–31% is reading them from SQLite; the timeline index is about 1%. Of the payload bytes read, 62–81% are command output, tool output and file-change diffs, and the wire projection drops or compacts them (command_execution.output becomes outputOmitted plus a failure flag, non-failed file_change diffs are removed, tool output is shortened). The change below covers the first two; I left tool output alone.

Change. Branch: https://github.com/bompus/t3code/tree/perf/history-page-output-facts (two commits on top of the index-cache branch; 9 files, +250/−27 including 144 lines of tests).

• getThreadHistoryPage removes the diffs of non-failed file changes in SQL (json_remove) before the payload is decoded.
• For command output, the wire projection only ever reads two facts: whether the output reports a failure (first 32 KiB) and whether it holds any text. Migration 063 adds a nullable output_facts column to the turn-item projection, written when the item is applied from the same function the wire projection uses. Rows with facts have $.output removed in SQL; rows without them (everything written before the change) take the old path unchanged.
• I tried cutting long command output in SQL instead (no schema change). It was slower on two of three threads, because SQLite unescapes and re-escapes the whole string.

Results. Same three threads, 12 warm scrollbacks per arm, arms interleaved across 6 rounds. The database copy was migrated with migration 063 and the facts were filled for those threads' command rows, so this is the cost once rows carry facts. All 27 pages hashed identical (sha256 of the page JSON) in every run of every arm.

Limits: runs spread 13–64% of their median, so the 24% row is the least certain. Host load was 2.5–5.8 during the runs. Event-loop gap beside the page time did not change beyond noise. Not measured: the WebSocket path, wire size, the cost of computing the facts when an item is written, or a thread whose rows were all written before the change (those keep today's cost until rewritten; there is no backfill).

For whoever reviews it. The one real decision is the schema column: it makes old rows slow and new rows fast, and a backfill would be a long migration over a large table. Leaving old rows alone seemed the safer default, but that is a call for you. Tests: the new differential test compares history pages against the wire projection for plain, failing, blank, long and legacy (no facts) outputs and fails if the failure bit is dropped; related suites pass. Two orchestration tests (Claude auth replay fixture, Claude background-wake) fail the same way on an unmodified branch.

Checking whether this was missed by triage: it was filed through the triage form about 7 hours ago and has only the via-triage label so far, no verdict. A similar issue filed from the same account today (#20790) got one within minutes.

The fix is ready and rebased on current main (one commit, +107/−30): https://github.com/bompus/t3code/tree/perf/history-page-index. I haven't opened a pull request and will do so once triage confirms the direction. Nothing else is needed from anyone if it's already queued.

Attempted on current main 70e5e384da, Linux, Node v24.21.0: installed dependencies, seeded an isolated worktree with migrate-dev-db, and started the web/server dev app. The server reached listening state and the browser reached the pairing route, but browser inspection then failed with code-mode host timed out waiting for wait response. No scrollback timing was obtained; this does not confirm or disprove the performance report. The available local threads also do not match the 13,000-item fixture. Please attach the offered synthetic seeding/measurement harness, including its invocation, so the reported workload can be replayed exactly. Leaving this open pending reproduction.

A real-data timing at a larger size: 0.1.2-nightly.20261022.3526, macOS, a 44.2 GiB statev2.sqlite.

The largest thread here has 78,268 turn items, about 210 MB of payload_json. I ran the readTimelineIndex turn-items SELECT for that thread with the sqlite3 CLI against the same database. One read took 7.4 s. A second thread has about 296 MB of turn items.

On this build getThreadHistoryPage and getTimelinePage both call readTimelineIndex inside sql.withTransaction. A history page in this thread therefore holds the writer and blocks the event loop for about that long, and every scroll-back page pays it again. Thread search (makeThreadFind) calls the same function.

The cached index on @bompus's branch would help when the same thread is paged repeatedly. A bounded page query on the reader connection would also fix the first page and avoid holding the writer.

I prepared a synthetic reproduction package for the workload requested in #20427. The accompanying t3-history-paging-synthetic.tar.gz contains history-paging.mjs, its README and a source manifest. It generates one thread and one completed run with 13,000 synthetic items, then calls the real projection-store history paging implementation.

With dependencies already installed in a separate checkout at ../t3code-reference, run this from the extracted package directory:

The output directory must be new. The script retains its synthetic SQLite database and JSON results, including item counts, raw per-page timings, source commit and Node version. It does not open or modify an existing database. The workload uses one warmup and three timed scrollbacks, each required to return all 13,000 seeded items.

The original run used Node v26.12.0. The relevant implementation matches upstream 6cecd22789f11fd325933a5d8859d6c09d6e7261; the package records the source identities. This preparation preserved the synthetic event generator and paging loop, removed machine-specific paths and unrelated modes, and added explicit source/output arguments.

I checked syntax, command-line behavior and package contents without seeding or measuring. I have not executed this adapted package end to end or verified compatibility or timings on current main. Import or schema differences fail rather than selecting another implementation. This measures server-side paging only, with uniform payloads and one run; it does not cover browser behavior, transport, fork inheritance, concurrent writers or the later third-party measurements.

t3-history-paging-synthetic.tar.gz

A per-thread index cache like the one in #24422 gained 38 to 53% on real threads when I ran it, not the 10× of the synthetic thread; most of what remains is decoding payloads that the page then drops.

I wrote the same cache earlier (one per-thread index, checked against the newest event of the thread and its fork sources) and have no plan to open a competing pull request. What I can add is what happened when I ran it on real data. The figures below are from my earlier comments here: real-data run and payload breakdown.

The cache gain is smaller on a real thread. On a copy of a long-used local database (14.9 GB), the three largest threads (12,291 to 16,809 visible items) scrolled from the newest window to the top through getThreadHistoryPage, in process, with a warm file cache. Median scrollback with and without the cache:

Run-to-run spread within an arm was 10 to 15%. A real page holds about 1,300 to 2,000 rows, so there are 6 to 11 pages instead of the synthetic thread's 72, and the rebuild that the cache removes is repeated far fewer times. One machine and one database; cold-disk behavior and the WebSocket path were not measured.

After the cache, most of a page is payload work. On the same kind of copy (three largest threads, 13.7k to 17.5k items), 63 to 75% of the remaining scrollback time was decoding the stored payloads and projecting them for the wire, 19 to 31% was reading them from SQLite, and the timeline index was about 1%. Of the payload bytes read, 62 to 81% were command output, tool output and file-change diffs that the wire projection drops or shortens.

A change that skips those bytes before decoding is on a branch, no pull request: perf/history-page-output-facts. Scrollback with the cache only, and with this change on top (12 warm runs per arm, arms interleaved):

Runs spread 13 to 64% of their median, so the 24% row is the least certain. All 27 pages hashed identical in every run. The branch needs a schema change (a nullable output_facts column on the turn-item projection), so rows written before it keep today's cost until rewritten; there is no backfill. It is based on an older main and has not been rebased on #24422.

If a maintainer wants this direction, I can rebase it on top of #24422 once that lands; otherwise I'll leave it as a branch.