orangeofcarl0-sys/dsh-fork-perf

README 摘要

dsh-fork-perf DSH（DeepSeek Harness）对话分支（fork）性能插件。 问题 dsh 0.1.0-rc.6 的 fork 路径对整个会话事件日志做 多次全量深拷贝 ，大会话（ 15MB） 一次 fork 产生数百毫秒同步阻塞，足以打断流式中的 LLM 响应（表现为 TRANSPORT/心跳 超时重试）、UI 卡顿甚至"卡死"： 环节 18.2MB/20k 事件实测 Session 构造器逐事件 snapshotJsonValue （纯 JS 深拷贝） 344ms persistence initFor 再 structuredClone(seed) 135ms write-behind enqueue 逐事件 structuredClone （分摊） 134ms 合计（fork 瞬时） 480ms 方案 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 完整还原所有补丁。 安装 注意：每次修改仓库代码后，需把 lib/ 、 cordis.patch.yml 、 package.json 同步到 /profiles/web/node modules/dsh-fork-perf/ （ file: 安装 不会自动跟随源文件更新），或重…

分类