Opening a long thread still takes 9–12 s on main, and each older page 3–4 s (follow-up to #24895)

Offen
  • Stimmt etwas nicht?
#36,128 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@juliusmarminge arbeitet bereits daran.

Seit 13.11.2026.

  • #36141 von @juliusmarminge — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
28/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
node.js, sqlite, typescript
Bereich
backend, databases, performance

Rechercherichtung

Start by reading getThreadSnapshotWindow and getThreadHistoryPage in apps/server/src/orchestration-v2/ProjectionStore.ts and the query plan behind each; the #29468 comment links the covering-index approach the local build uses. Check the open pull request #36141 before touching anything, since it may already cover this work. Reproducing needs the 49 GB statev2.sqlite clone read through the real reader worker, so confirm you can get a comparable dataset first. Done looks like thread-open and older-page timings on main approaching the local-build numbers, with a query plan showing payloads are no longer decoded for run and attempt metadata.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

#24895 and #20427 were closed on November 11. On main at a044f0c0b3, opening our two coordinator threads and paging back still takes:

Read Thread A / B on main Our local build
Thread open: getThreadSnapshotWindow 11.0–11.6 / 9.1–9.8 s 3.7–4.9 s
Each older page: getThreadHistoryPage 3.0–4.2 / 2.9–3.6 s 1.0–2.1 s

Setup: a block clone of our 49 GB statev2.sqlite, read through the real ProjectionStore (reader worker, node:sqlite), read-only, two passes. Thread A has 7,352 runs and 62,950 turn items, thread B 6,886 runs and 59,668. Our local build was measured on the same clone earlier.

Where the time goes on thread A, second pass:

  • Thread open, 10.8 s:

    • the recursive retained-node read, 3.2 s;
    • checkpoints, 2.3 s;
    • provider turns, attempts and runs, 1.0–1.1 s each;
    • subagents and context transfers, 0.9 s each.

    The live-or-recent reads (status IN (...) OR ...) still take about a second each on a thread with 7,000 runs.

  • Each older page, 3.2 s: all runs, 1.1 s, and all attempts, 1.1 s, are read to render one page. A count of the earlier items takes another 0.4 s.

Our build takes a page's run and attempt metadata from covering indexes instead of decoding every payload. The #29468 comment links the code. Every thread switch to a long thread pays the open cost, and every scroll back pays the page cost.

Measured and written by Claude (Opus 5.5) in T3 Code; posted with the owner's approval.

Vorherrschende Sprache
TypeScript
Sterne
24.8k
Forks
6.4k
Ø Merge
59 Min.
Gemergte PRs (30 T.)
418

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus pingdotgg/t3code

Alle Issues in pingdotgg/t3code

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.