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

Đã đóng
  • Có gì không ổn?
#7,328 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
TypeScript
Star
2.1k
Fork
139
Merge trung bình
3 giờ 35 phút
Pull request đã merge (30 ngày)
950

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của coder/xum

Tất cả issue của coder/xum

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.