🤖 perf: plan the turn's system sections in one pass over the history
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Refactor
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
- Domain
- performance
Research direction
Start with src/node/utils/messages/volatileSystemTail.ts and read how withRecordedRows and the four planning functions process segment history. Check the existing volatileSystemTail and replay-verify tests before changing the shared traversal. Done means the sections are planned from one history pass, output stays byte-identical, and those tests pass; the issue says this work is low priority until one of its listed triggers occurs.
Written by the indexing model from the issue text.
Description
Problem
Each turn plans 4 system sections over the same history, one pass per section:
- volatile tail (
planVolatileSystemTail) - custom instructions (#7304,
planCustomInstructions) - skill index (#7308,
planSkillIndex) - tool instructions (#7323,
planToolInstructions)
Once a segment has a frozen record, each plan slices the segment after the latest context boundary, collects its records, and rebuilds the whole message array with one flatMap (withRecordedRows in src/node/utils/messages/volatileSystemTail.ts). So the cost per turn grows with (sections x history length).
Numbers
Measured on main 42c551ec10 with bun, a synthetic segment with a frozen record on every channel, and a user row last. Host load was about 30, so the absolute values are high, but the ratio holds.
| Rows in history | 1 section (before #7304) | 4 sections (now) |
|---|---|---|
| 1,000 | 0.07-0.08 ms | 0.13-0.16 ms |
| 10,000 | 0.19-0.24 ms | 0.72-0.90 ms |
| 100,000 | 1.9-2.5 ms | 8.4-9.9 ms |
This is well below the send-path line I act on (50 ms per turn, #6912). It is low priority today.
Fix (when it is worth it)
Read the segment once: one boundary search, one loop that collects the records of all channels, and one flatMap that puts back every channel's rows. Each channel's plan then works from the shared records. The output must stay byte-identical: the existing volatileSystemTail and replay-verify tests cover the row order.
Triggers
- A fifth section joins this pattern, or
- a live capture or nightly shows section planning at 5 ms or more per turn, or
- segments of 100k+ rows become common.
Refs #7304 #7308 #7323. Earlier measurement: #7308 issuecomment-6361801415.
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
- Dominant language
- TypeScript
- Stars
- 2.1k
- Forks
- 140
- Avg merge
- 4h 57m
- Merged PRs (30d)
- 946
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from coder/xum
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
🤖 fix: a Daytona connection test started before a settings save can show the old key as connectedOpen
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
MoonshotAI/kimi-code#4398 ·
Maintainers usually reply within 1 day
-
Xiaomi Mimo语音识别服务异常Openpending triage
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
package-lock.json : les binaires natifs macOS et Linux de unrs-resolver ont disparu depuis #1823Openbug dependencies
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
AxaFrance/design-system#2064 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100