dsh-fork-perf

dsh-fork-perf

DSH（DeepSeek Harness）对话分支（fork）性能插件。

问题

dsh 0.1.0-rc.6 的 fork 路径对整个会话事件日志做多次全量深拷贝，大会话（>15MB）
一次 fork 产生数百毫秒同步阻塞，足以打断流式中的 LLM 响应（表现为 TRANSPORT/心跳
超时重试）、UI 卡顿甚至"卡死"：

方案

1. 零拷贝 fork（zeroCopyFork）：fork 的 seed 事件本就是 deepFreeze 的不可变
   纯 JSON 树。补丁改走 Session.prepare(..., { seedSource: 'persistence' }) 的
   fromRestore 通道——原地冻结复用引用，跳过整树深拷贝。子会话 header
   （parentSession/seedLength/cwd）与官方 fork 逐字段一致，磁盘布局不变。
2. fast init-for（fastInitFor）：PersistenceCoordinator.initFor 里那次
   structuredClone(seed) 替换为冻结引用复用。带 rc.6 源码特征校验
   （structuredClone(e) 标记），内部结构不匹配时自动跳过并告警。
3. 监控与 API：fork 计时/路径统计；/dsh-fork-perf/api HTTP 路由。

实测同负载：fork 主体 344ms → 19ms（≈18×）；initFor 135ms → ~0ms。

安全性

• 共享引用等价于深拷贝：事件在进入源会话时已通过完整 JSON 边界与 surface 验证并
  深冻结，任何代码都无法修改。
• 三层回退：(a) 调用时能力探测缺失方法 → 官方实现；(b) restore 通道运行时异常 →
  try/catch 回退官方实现；(c) 配置开关 zeroCopyFork: false → 永远官方路径。
• dispose 完整还原所有补丁。

安装

# 从 GitHub 安装（推荐）
dsh plugin --profile web add github:orangeofcarl0-sys/dsh-fork-perf
# 或
dsh plugin --profile web add https://github.com/orangeofcarl0-sys/dsh-fork-perf

# 本地开发
dsh plugin --profile web add file:<本仓库路径>

注意：每次修改仓库代码后，需把 lib/、cordis.patch.yml、package.json
同步到 <DSH_HOME>/profiles/web/node_modules/dsh-fork-perf/（file: 安装
不会自动跟随源文件更新），或重新执行 dsh plugin add。

重启 dsh web 生效。日志出现 [fork-perf] zero-copy fork installed 即成功。

API

POST http://127.0.0.1:3080/dsh-fork-perf/api/<method>：

• stats.get — fork 次数 / 零拷贝占比 / 回退次数 / 最近记录（事件数、耗时、路径）
• stats.reset — 清零
• config.get / config.set — 运行时开关（zeroCopyFork、fastInitFor、
  slowForkWarnMs、keepRecent），config.set 同时写 settings 持久化

curl -X POST http://127.0.0.1:3080/dsh-fork-perf/api/stats.get
curl -X POST http://127.0.0.1:3080/dsh-fork-perf/api/config.set \
  -d '{"zeroCopyFork": false}'

验证

• smoke_test.mjs（14 断言）：官方 fork 基线 / 零拷贝 fork 功能等价
  （header、事件数、深冻结、boundary、open-turn 拒绝）/ dispose 还原 /
  版本漂移回退 —— ALL PASS
• test_fast_initfor.mjs（8 断言）：initFor 补丁安装 / 源码特征漂移跳过 /
  无 persistence 服务存活 —— ALL PASS
• bench_fork2.mjs：18.2MB/20k 事件，fork 主体 343.8ms → 18.8ms

局限

• enqueue 的逐事件 structuredClone（第三次拷贝）在插件层无法安全消除——它在
  write-behind 闭包内部，且承担"persistence 独立于生产者"的所有权语义。根治需
  上游改为按需快照。
• 补丁绑定 rc.6 内部结构（_forkSeed、initFor 源码特征）；大版本升级后特征
  校验会自动跳过优化并保持官方行为，重新适配即可。