[性能] dsh web 启动 6-7s：client-modules bundle 组装逐字符扫描约 15MB 源码（附 CPU profile 数据）

[caesarjue]

Summary

dsh web 启动到打印带 token 的 URL 需 6-7 秒。经 CPU profile 定位，约一半 CPU 时间消耗在 @deepseek-ai/dsh-client-modules 的启动期 client bundle 组装上：该模块在 JS 层对全部 client 半源码（本机实测约 14.9 MB）逐字符扫描并构建 sourcemap 段映射，且没有磁盘缓存，所以每次进程启动都要完整重算。

Reproduction

1. dsh 0.1.5-rc.1，profile web 装配插件（本机 176 个，其中第三方 client.js 合计 4.24 MB）
2. 执行 dsh web --no-open，计时"启动 → 打印 http://127.0.0.1:3080/?token=..."
3. 性能采集命令（可复现）：

   /usr/bin/time -l dsh web --no-open
   node --cpu-prof --cpu-prof-dir=/tmp/prof <dsh>/lib/bin.js web --no-open
   sample <pid> 3 -file /tmp/sample.txt

Current behavior

耗时：连续两次启动分别 6.6s / 6.1s（稳定复现，排除首次冷启动/缓存因素）。

CPU 分解（/usr/bin/time -l）：

real 7.26s   user 6.88s   sys 0.79s
maximum resident set size: 838 MB

user + sys ≈ real → 纯 CPU-bound，不是网络或磁盘等待。

node --cpu-prof 热点（按自身耗时聚合，已剔除 idle）：

函数	耗时	位置
buildCombo	1.37s	@deepseek-ai/dsh-client-modules/lib/index.js:277
newlineCount	1.24s	同文件 :240
utf8Write	0.86s	node buffer
identitySectionMap	0.75s	同文件 :266
sourceURL / sourceMappingURL 正则	0.22s	—
GC	0.22s	—

按模块聚合：@deepseek-ai/dsh-client-modules 占实际 CPU 约 47%。

需要处理的 client 代码体量：

• 第三方插件 client.js：20 个文件 / 4.24 MB（最大 @xmanrui/dsh-im 918 KB）
• 官方内置 client 模块：65 个文件 / 10.66 MB，其中 dsh-client-ui-sidebar-documentpreview 单个 6.7 MB（占总量 45%）
• 合计 ≈ 14.9 MB

可疑实现（dsh-client-modules/lib/index.js:240）：

/** Count generated lines while assembling indexed-map section offsets. */
function newlineCount(value) {
  let count = 0;
  for (const char of value) if (char === "\n") count += 1;
  return count;
}

逐字符 for...of 迭代 + 字符串比较：对约 15 MB 文本相当于千万级迭代，实测 1.24s。代码中只看到进程内缓存（loadCache / pkgMeta），未发现磁盘缓存。

Expected behavior

期望启动耗时明显低于当前水平（例如 < 2s）；至少重复启动时不必重新计算未变更的 bundle 组装结果。

优化建议（按预估收益排序，仅供参考）：

1. newlineCount 改用 indexOf 循环或等价高效写法（预计 1.24s → 数十 ms 量级）
2. 组装产物（combo bundle + 段映射）落磁盘缓存，以各 client 源文件的 mtime/size 为 key，未变更时直接复用
3. dsh-client-ui-sidebar-documentpreview（6.7 MB）考虑拆分或按需加载，减少默认扫描量
4. 若架构允许，把这类纯计算移入 Worker，避免阻塞进程启动关键路径

Environment

• dsh: 0.1.5-rc.1（npm latest）
• OS: macOS 26.6.2（Apple Silicon / M4）
• Node: v24.18.0
• profile: web，插件 176 个（含大量第三方 client 半）
• 启动命令：dsh web --no-open
• 采集工具：/usr/bin/time -l、node --cpu-prof、sample

[Start-Gao]

这条热点（newlineCount 逐字符扫描 / buildCombo）的上游归因我单独发了一帖：#6391

要点：热点之所以被放大 8 倍，是因为 client-modules 的注册表自 0.1.5 起随 loader 立即构造，此后每一波插件激活都会触发一次同步全量重组合（实测 1 次 → 8 次，0.43s → 14.0s）；引入提交是 19444907「feat: electron 打包」。在 0.1.5-rc.1 上单文件换回旧 client-modules，启动 17.3s → 4.28s。

你 profile 里的量级（10.66MB / ui-sidebar-documentpreview 6.7MB）与我这边独立测量完全一致。

[cningan]

补充一份 Windows 侧的独立测量（原帖给的是 profile 自身耗时，这里给改掉它之后启动实际快多少的端到端数字），另附一个"上游至今未修"的核对。

环境：Windows 11，Node v24.15.0，@deepseek-ai/dsh@0.1.5-rc.1（npm latest），真实 web profile 组合树 168 条目，其中带 dsh.client 且启用的 61 个 / 11.52MB（最大 ui-sidebar-documentpreview 6.57MB——与你测到的 6.7MB 一致）。全部测量在隔离实例 dsh --profile web --port 0 --no-open 上做，不碰正在运行的宿主。

1) 只改 newlineCount，启动实测（内存内改写该函数实现，磁盘上一个字节没动）

	启动到打印 dsh web: <url>	单次 compose
现状	8.02s / 8.31s	500–630ms
仅把 for (const char of value) 换成 indexOf 循环	5.67s / 5.67s	267–345ms

→ 端到端 −2.5s，与你「1.24s → 数十 ms」的预估同向、幅度更大。原因是这个函数每轮被调用多次（批次 combo 一遍 + 每个包的单包 combo 一遍 + identitySectionMap 内再扫一遍），单轮累计扫描约 44MB（每个字节约被扫 3.8 遍），再乘上 #6391 说的重组合次数。

2) 该处在 0.1.6-alpha.1 仍未修（npm pack 取包逐字比对，未安装到本机）

• 0.1.5-rc.2 与 0.1.6-alpha.1 的 @deepseek-ai/dsh-client-modules/lib/index.js：newlineCount 与现装 0.1.5-rc.1 逐字相同（同为逐字符 for...of）。
• @deepseek-ai/dsh-client-ui-sidebar-documentpreview 的 lib/client.js：0.1.5-rc.1 6.57MB、0.1.6-alpha.1 6.58MB，首行仍是 //! Bundled PDF.js license notices（pdfjs-dist 6.3.289 整体内联）。

即：原帖建议的 1 与 3 两条，在最新的 alpha 上都还没有落地。

3) 测量手段（可复现，供维护者取用）

• CPU profile 的落盘坑：Node 只在正常退出时写 .cpuprofile，而隔离实例通常是被 taskkill /F 收掉的，采到的会丢——我加了一个 EXIT_AFTER_MS 预加载让它在采样窗口后自行退出。
• 计数与验证都在加载期做，不改磁盘：用 Node ≥22.15 的 module.registerHooks 在加载 dsh-client-modules/lib/index.js 时改写源码——一个钩子把 compose() 拆成"计时包装 + 原实现"，另一个钩子把 newlineCount 换成 indexOf 实现，于是"跑了几次、每次多久、改完省多少"都是实测而非推算。