Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

🤖 perf: plan the turn's system sections in one pass over the history

Aperta
  • Qualcosa non va?
#7,328 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
performance

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

Each turn plans 4 system sections over the same history, one pass per section:

  1. volatile tail (planVolatileSystemTail)
  2. custom instructions (#7304, planCustomInstructions)
  3. skill index (#7308, planSkillIndex)
  4. 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

Lingua principale
TypeScript
Stelle
2.1k
Fork
140
Merge medio
5h 8m
PR unite (30g)
952

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di coder/xum

Tutte le issue di coder/xum

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.