[Bug Report] TokenMeter 在每次会话事件后重建完整事件快照，长会话二次方级退化（回调已携带 event 却未使用）

[DRAG0NM]

摘要

长会话（大量 assistant/chunk）下 TokenMeter 产生 O(n²) 退化：每次 session.append 都会使 session.events 快照失效（eventsSnapshot = undefined），而 TokenMeter 的 session/event 监听器只取 session 参数、弃用了回调本就携带的 event，随后在 _sync() 里访问 session.events getter 触发全量日志拷贝——每 append 一次就 O(n) 重建快照，却只消费 1 个新事件。发帖人实测 32K 事件时 active meter 1657ms vs inactive 476ms（约 3.5 倍、二次方增长）。

复现步骤

1. 启动 dsh，创建会话，开启 TokenMeter（默认 bundle 下已激活）。
2. 让模型持续流式输出（每 chunk 一次 assistant/chunk append），或回放长会话日志。
3. 观察 append/测量耗时随事件数增长：8K → 16K → 32K 事件，active meter 分别约 215 / 404 / 1657 ms（发帖人实测，二次方增长；inactive 对照 162 / 246 / 476 ms）。
4. 会话越长，每轮 agent 循环与 UI 更新越卡（与 deepseek-harness在使用中如果上下文长度到达一定地步会卡死浏览器一会 #211 长上下文卡死同现象域）。

根因（源码定位，rc.6）

1. session.events 是"失效即全量重建"的快照 — @deepseek-ai/dsh-session/lib/index.js：

   • L1397-1400：get events() { this.eventsSnapshot ??= Object.freeze([...this.log]); return this.eventsSnapshot; } —— 快照缺失时对完整日志做浅拷贝（O(n)）；
   • L1470-1471 append()：this.log.push(event); this.eventsSnapshot = void 0; —— 每个 append 都使快照失效；模型每输出一个 chunk 就是一次 append。

2. session/event 回调本来就携带新事件，监听器却弃用 — 同文件：

   • L1464-1472：append 发布回调时 const callbackArgs = [this, event]，invokeContainedSessionObservers(..., "session/event", ..., callbackArgs) —— 监听器能直接拿到刚 append 的 event；
   • @deepseek-ai/dsh-token-meter/lib/index.js L424-426：ctx.on("session/event", (session) => { if (this.states.has(session)) this._sync(session); }) —— 只取 session 参数。

3. _sync() 每次访问 session.events 触发全量重建 — dsh-token-meter/lib/index.js L485-504：

   while (state.consumedEvents < session.events.length) {
     const event = session.events[state.consumedEvents];
     this._foldEvent(session, state, event);
     state.consumedEvents += 1;
   }

   快照刚被 append 失效，session.events getter 重建整个日志副本，而循环通常只 fold 1 个新事件 → 每 append O(n)，总计 O(n²)。

4. 注意：fold 逻辑本身已是增量设计（consumedEvents 游标），瓶颈不在 fold 而在快照失效-重建。_estimateProviderAssistant（L578-594）在 assistant/message 时还会按 sourceEventSeqs 读 session.events[seq]（L587）——替换溯源需求，修复时需保留该能力。

建议修复

方案 A（推荐）· 消费回调携带的 event，绕开快照重建：

• token-meter L424 改为 ctx.on("session/event", (session, event) => { if (this.states.has(session)) this._foldEvent(session, state, event); })（增量 fold 单个新事件），仅冷启动/补偿时全量 _sync()；
• 为 _estimateProviderAssistant 的 L587 提供 O(1) 按序访问（如给 dsh-session 增加 eventAt(seq)——log 是数组可直接下标，或在回调内收集本次 sourceSeqs 需要的旧事件）。热路径零快照重建，消除二次方项。

方案 B · 优化 dsh-session 的 events getter 缓存：append 后不立即失效快照（延迟重建/不可变增量视图）。改动在公共 API 语义层，影响面大，但所有 session.events 消费者（含 UI 会话渲染）共同受益。

方案 C · token-meter 微任务合并：多个 append 合并为一次同步。治标不治本，快照重建次数虽降但每次仍 O(n)。

影响

• 长会话/长流式输出时 agent 循环与 UI 每轮 append 同步开销二次方增长（发帖人实测 32K 事件 3.5 倍、1657ms），会话越长越明显，与 deepseek-harness在使用中如果上下文长度到达一定地步会卡死浏览器一会 #211（上下文过长 Web 卡死）同现象域；
• 所有使用 TokenMeter 的路径受影响（measure 与事件监听双入口，L424-426/L444-445）；
• 每个模型 chunk 都触发一次全量拷贝，token 计数本身越活跃开销越大。

环境

• 源码定位：0.1.0-rc.6（npx 缓存安装包，Node v24.16.0，Windows 11）
• 原报告：[性能问题] TokenMeter 在每个会话事件后重建完整快照，导致二次方级性能退化 #238（发帖人实测数据：8K/16K/32K 事件 215/404/1657 ms）

验证材料

• 发帖人实测对照（inactive vs active meter，二次方增长）；
• rc.6 源码逐行核对：dsh-session/lib/index.js L1397-1400/L1470-1471/L1464-1472 与 dsh-token-meter/lib/index.js L424-426/L485-504/L578-594；
• 机制推演：每 append → 快照失效 → 监听器弃用 event → _sync 访问 session.events → O(n) 拷贝 → 总 O(n²)。

---

First analysis of discussion #238. Happy to open a PR with fix option A.

[TTTPOB]

dsh-hang.cpuprofile
ran into similar problem, here is my v8 profile result. might help

[DRAG0NM]

Thanks for the CPU profile — a real hang sample is exactly what the O(n^2) snapshot-path analysis benefits from. We'll cross-check the hot frames against TokenMeter's rebuild loop.