Repository navigation
P2: threads:changed regrew to 4.6 MB per push (1,093 archived rows, hypotheses and suggestions for every thread) #1385
Description
Follow-up to #617 (closed). The main-side listThreads cache landed, but the payload itself grew with the store.
Measured (production listThreads against a copy of the live store, 2026-09-29)
- 1,829 rows, 4.59 MB JSON / 4.52 MB v8 structured clone per push
- 1,093 of those rows (60%) are archived threads
- Fattest fields summed over all rows:
hypotheses1.13 MB,suggestions1.0 MB,sandbox216 KB. These ride on every row, although the sidebar only needs them for the open thread. - Main-side cost is small (decorate 4 ms, serialize 3 ms). The cost is IPC plus the renderer's deserialize and
reconcileThreadListof 4.6 MB each time.
Frequency
stampLastEvent rewrites lastEventAt every ~5 s per active thread (runner.js stampLastEvent). That replaces the threads array, which invalidates the cache, so the next pushThreadsChanged ships the full list. With 5 threads working that's ~1 full push/s (~4.5 MB/s). Sampled renderer CPU at 7–17% while 5 threads streamed.
Fix direction
- Drop
hypothesesandsuggestions(and probablysandbox) from list rows; the detail view already loads per thread. - Exclude archived rows from the live push and fetch them when the Archived view opens, or send row deltas keyed by id.
- Optionally keep
lastEventAtoff the list-invalidating path (watchdog-only field).
Activity
Drop detail-only fields from threads:changed rows (#1389)
currentbits commentedon Sep 29, 2026
First cut is in #1389 (merged, 3988ab5): list rows drop
hypothesesandsuggestions, taking the push from 4.59 MB to 2.44 MB on the live-store copy.Still open here:
lastEventAtstamps from invalidating the list cache every 5 s per active thread.currentbits commentedon Sep 29, 2026
Correction: the frequency claim in this issue is wrong. I measured it with a real
createRunner, a fake Claude streaming text deltas and tool calls, and 300 ballast threads. The runner sendsthreads:changed3 times per turn (both a 1.3 s and a 12.7 s turn), and none of those pushes repeat an identical array.stampLastEventupdates the store but does not trigger a push; pushes happen at turn state transitions and on UI/IPC actions.So the cost is a few pushes per turn times the payload size. #1389 already cut the payload by 47%. The remaining item, excluding archived rows, is lower priority than the original "~4.5 MB/s" framing suggested, and deduping identical pushes would save nothing on the runner path. The renderer CPU I sampled during streaming is more likely detail pushes than list pushes.
currentbits commentedon Oct 9, 2026
Fixed: fields dropped (3988ab5, #1389) and pushes moved to row patches (8e77940). Archived rows still ride the full base push; reopen if that measures large again. Closing in the 2026-10-09 board cleanup (#1532).