[Bug][Desktop/Win] 启动后约 80 秒单核满载 + 约 900 MB 读取：dsh-settings describe() 每次调用都重算整个 profile 组合

[kiriyama-rain]

Summary

Windows 桌面端每次启动后，宿主进程会持续约 80 秒跑满一个 CPU 核心，并读取约 900 MB 数据；这段时间里插件树 / 设置页 / 新建会话 / 历史列表都明显卡顿。根因是配置描述路径每次调用都会重新组合整个 profile：dsh-settings 的 describe() → dsh-config-editor 的 configuration() → loadProfileDirectory() 全量重读 + 重解析 profile patch 与全部 bundle manifest，启动期约 1,500 次。

Reproduction

不需要桌面端，用同一份 profile 内容在隔离的 DSH_HOME 里跑 CLI 即可复现（profile 名避开保留名 desktop）：

$env:DSH_HOME='C:\Users\<u>\.dsh-boottest'   # junction/复制 sessions、plugins、profile 目录与 node_modules
& <node.exe> "<...>\@deepseek-ai\dsh\lib\bin.js" --profile <profile> --no-open --port 19488

再用一个 fs 级 spy（--require 注入，包裹 fs.readFileSync / fs.promises.readFile / createReadStream / FileHandle.read 等）统计路径级读取次数，或直接采样宿主进程的 CPU 与 IO。

最小形态：profile 约 35 个 bundle、cordis.patch.yml 约 300 KB。

Current behavior

• dsh-settings 的 SettingsForms#describe()（dsh-settings/lib/index.js:413）在第 415 行调用 this.ownerContext.configEditor.configuration()。
• dsh-config-editor 的 ConfigEditor#configuration()（dsh-config-editor/lib/index.js:39-53）每次都执行 loadProfileDirectory("dsh", profile.dir, profile.installAnchor)，即重新读取并解析 profile patch 与每个 bundle 的 package.json / cordis.patch.yml。
• 启动期 describe() 被调用约 1,500 次 ⇒ 整个 profile 组合被重算约 1,500 次。

spy 抓到的调用栈（采样文件 = profile 的 cordis.patch.yml，217.5 MB / 845 次）：

fs.readFileSync
 → loadOverlayPatches      (dsh-app-boot/lib/index.js:3530)
 → loadProfileDirectory    (dsh-app-boot/lib/index.js:947)
 → ConfigEditor#configuration (dsh-config-editor/lib/index.js:41)
 → SettingsForms#describe  (dsh-settings/lib/index.js:415)

spy 逐路径计数（一次冷启动，95 秒窗口内）：

文件	读取量	次数
profiles/<p>/cordis.patch.yml	219.31 MB	852
@deepseek-ai/dsh-app-boot/package.json	65.06 MB	30,468
@deepseek-ai/dsh-web-app/cordis.patch.yml	17.30 MB	848
@deepseek-ai/dsh-base/cordis.patch.yml	16.77 MB	848

（其余为 client bundle 的一次性读取，属正常开销。）

CDP CPU profile（隔离实例，140 s / 88,064 样本，非 idle 主体）：structuredClone(13.3%)、existsSync(12.1%)、readFileUtf8(10.2%)，其后 js-yaml 4.25 s、schemastery 3.75 s、readProfileManifest / getDshRuntimeVersion / packageDirFromAnchor / applyEntryPatches 等。

实测对照（同一 profile 内容、同一份框架代码，隔离启动）：

指标	修复前	只缓存 configuration() 后
启动期 CPU	100% 单核 × 80 s	95 s 内总计 17 s，尾段 0.02–0.4 s/5 s
磁盘读	905.9 MB	138 MB
组合重算	1,502 次	真实重解析 15 次，共 783 ms
describe() 实际执行	约 1,500 次	3 次
工作集	470 → 644 MB 不回落	峰值 425 MB，回落到 259 MB

另一个观察：SettingsForms#invalidate()（dsh-settings/lib/index.js:382）用 queueMicrotask 合并失效通知，实测整轮启动只被调用 18 次，而 describe() 约 1,500 次 —— 这个合并并未限制重算次数（跨 await 边界合不上），所以"失效通知"不是节流点。

Expected behavior

组合结果应按 profile 文件的版本缓存，只在真正变更时重算；启动期的批量 describe() 不应触发上千次全量组合。建议（任一即可）：

1. ConfigEditor#configuration() 缓存组合结果，键 = profile cordis.patch.yml / package.json / home patch 的 (mtime, size)，并在 loader reload 事件里显式失效；
2. loadProfileDirectory() 自身加 manifest 级缓存（同一个 package.json 被读 3 万次本身也不合理）；
3. describe() 结果按 entry + 组合版本缓存；
4. invalidate() 换成真正的节流/去抖（覆盖 await 边界）。

Environment

• DSH Desktop (Electron) on Windows 11；包版本 @deepseek-ai/dsh-* 0.2.0-rc.2（asar 内与 npm 全局安装两份 dsh-config-editor / dsh-settings 字节一致）
• profile：desktop，约 35 个 bundle，cordis.patch.yml 304 KB（内含 !!js 自定义标签，插件较多）
• 复现不依赖桌面端：CLI dsh --profile <p> --no-open --port 19488 同样复现

本地规避（供参考，不改任何 DSH 文件）

以用户插件（preset-code/*.mjs + cordis.patch.yml 的 insert 行）在运行期给 ConfigEditor.prototype.configuration 加 (mtime,size) + TTL 缓存、给 SettingsForms.prototype.invalidate 加节流，即可完全消除启动风暴（数据见上表）。

相关

• [Bug] Desktop 0.2.0-rc.2 on Windows: renderer keeps one CPU core busy (60-130%) while the client is idle; input lags #9637（Desktop 0.2.0-rc.2 on Windows: renderer keeps one CPU core busy while the client is idle）
• [Performance] Web UI: an active session tab keeps burning 1+ CPU core and its memory grows unbounded #9679（[Performance] Web UI: an active session tab keeps burning 1+ CPU core）

这两条描述的是 renderer 常驻占用；本条是宿主冷启动 80 秒的 CPU/IO 风暴，机制不同（配置组合重算），可独立修复。

[argszero]

Thanks for the measurement — the mechanism reproduces in the source, and your numbers cross-check against what a single call actually touches. I read this against master = 571902028a75c64c1d767f4ae5fd099485f0ddf0.

What one configuration() call reads

packages/boot/config-editor/src/index.ts:49-51:

configuration(): Array<{ entry: Entry; inherited: Record<string, unknown>; override: Record<string, unknown> }> {
    const profile = this.ownerContext.profileContext
    const loaded = loadProfileDirectory('dsh', profile.dir, profile.installAnchor)

That call passes no options, so loadProfileDirectory's userLayer stays undefined and the profile's own cordis.patch.yml is read and re-parsed with js-yaml on every pass (packages/boot/app-boot/src/profile.ts:739, :768-771). A sibling caller opts out on purpose when it does not need that layer — readBundlePatches in packages/boot/app-boot/src/profile-context.ts passes { userLayer: false }.

The bundle loop is profile.ts:751-765: for each name in dsh.profile.bundles, resolveBundleDir → packageDirFromAnchor (:694-704) walks createRequire(anchor).resolve.paths(name) with an existsSync per candidate; then readProfileManifest(binName, packageDir) (:610-623) runs readFileSync + JSON.parse; then evaluatePluginCompatibility; then loadOverlayPatches over every patch file the bundle declares; and finally the structuredClone-heavy composeEntries.

Your table cross-checks on exactly that shape. In the same cold-start window, 30,468 ÷ 852 ≈ 35.8 manifest reads per profile-patch read, against a ~35-bundle profile — i.e. about one manifest probe-and-read per bundle per composition. And 65.06 MB ÷ 30,468 ≈ 2.1 KB, which is the size of one package.json. So the 900 MB is not one pathological read: it is ~36 small reads multiplied by ~850 compositions, plus the parse work on top.

describe() calls configuration() exactly once per call — packages/settings/settings/src/index.ts:304 — so "1,500 describe() ⇒ 1,500 recompositions" holds by construction.

A correction to suggested fix 1: the key is missing the bundle side

The inputs to configuration() are:

• the profile package.json (profile.ts:745),
• the profile's cordis.patch.yml (:768-771),
• each bundle's package.json (:753),
• each bundle's declared patch files (:762).

The home patch ($DSH_HOME/cordis.patch.yml) is not read by this path — it enters through readProfilePatches, which the Loader uses, not configuration(). So a (mtime, size) key over "profile patch + profile package.json + home patch" would miss the ~35 manifests and the bundle patch files, which is where most of the 30,468 reads come from.

invalidate() is not a throttle — but there is a reload signal to hang invalidation on

Confirmed at settings/src/index.ts:279-286: the flag is cleared at the top of the microtask (before describe() runs), so the guard only coalesces calls made inside one tick and bounds nothing across ticks. That matches your 18-versus-1,500 measurement, but it also means invalidate() is not where the 1,500 come from — those come from the other host-side callers: packages/api/session-controller/src/catalog.ts:103, packages/api/settings-controller/src/index.ts:103 and :206, plus the write path's own describe() at :391 / :422.

There is a reload event to key invalidation on, and it is already used one package over: settings/src/index.ts:234 subscribes to app-boot/config-reload, emitted after every successful recomposition at packages/boot/app-boot/src/index.ts:411. Any cache here should be dropped from that event as well as from the file fingerprint — the event is the only thing that covers a bundle patch edited in place.

The plugin path, and the boundary it cannot close

The memoization is mountable without forking: ConfigEditor is a Cordis Service named configEditor (config-editor/src/index.ts:26-29), and describe() reaches it as this.ownerContext.configEditor.configuration() (settings/src/index.ts:304) — through the live instance. Shadowing configuration on that instance (an own property, not a prototype patch) intercepts every caller.

One trap worth knowing, since a sibling report hit it: ctx.get() hands back a traceable proxy, so a property write on the view is a silent no-op. The write has to land on the raw instance — view[Symbol.for('cordis.original')], equivalently ctx.reflect._getImpl(name).value.

The residual boundary: with only the profile-level files in the key, a bundle patch that changed without a reload is not noticed. app-boot/config-reload covers install / remove / upgrade, so the window is narrow, but it is a window — which is why fix 1 upstream remains the durable one.

For what it is worth, we met the same shape (a derived index re-read in full on every call) in the DeepSeek upload index and shipped the fix as a plugin: @argszero/dsh-upload-index-cache memoizes the index load on an (ino, size, mtimeMs) key. Same technique, different index — it does not address this one.

The same cost is paid again on every save

edit() recomposes independently: config-editor/src/index.ts:99 and :136 each call loadProfileDirectory directly, on top of the describe() that write() runs for its revision check. So a settings save costs three or four full compositions. Caching inside configuration() alone would not cover those two — a manifest-level cache inside loadProfileDirectory would, which is your option 2 and the one that also collapses the 30,468 reads.

[argszero]

Follow-up: I shipped the cache this path was missing, as a plugin — @argszero/dsh-profile-composition-cache@0.1.0 (source: argszero/dsh-profile-composition-cache).

dsh plugin --profile <profile> add @argszero/dsh-profile-composition-cache

One line of usage, then restart: the first configuration() call composes as shipped and records the files it read, and every later call is served from that composition while those files are unchanged.

What it changes, and what it deliberately does not

It shadows configuration() on the live configEditor instance. A hit answers from the composition the harness itself produced; a miss calls the shipped implementation exactly once. So the plugin never composes a profile — it only decides whether it has to. That is the property that makes a cache on this path safe to mount at all: it can change how often a configuration is computed, never what it means.

Validity is the file identity (mtimeMs, size, ino) of everything the composition reads — the profile's package.json, its cordis.patch.yml, its compatibility.json, each bundle's package.json, and each bundle's declared patch files. ino is not decoration: writeFileAtomic publishes by rename, so a replacement can arrive with a length the writer chose and a timestamp it preserved, and the inode is the field that moves.

Two inputs are not files, and both are in the identity: the entry list the call is about to describe (a Loader reconciliation can hand back an identically named but different Entry object, and the rows carry the entry itself), and a generation bumped by app-boot/config-reload — the signal already in the tree, which is why this needed no new event.

The cost, measured rather than asserted, on a fixture profile with one bundle:

	profile loads	shipped configuration()
a miss	2	1
a hit	0	0

Two loads on a miss, not one: the inputs have to be recorded before the composition runs (see below), and recording them means reading the profile once to find out which files the composition is about to read. So the first call inside a window is somewhat more expensive than the shipped path, and the ~1,500 calls that follow it in your measurement cost one stat per recorded input and no parsing at all. If a profile ever ends up in a state where every call is a miss, this plugin is a small net loss — that is what the debug reasons are for, to tell you which of the four happened.

Three details worth naming, because each is a way a cache on this path could be wrong:

• The inputs are recorded before the composition, not after it. Rows are a function of the disk as it looked while each file was read. Filing them under the identity observed afterwards means a rewrite landing mid-composition (another process running dsh plugin add, an editor saving the patch) matches the disk and is served as current until something else moves. There is a test for exactly this, and a mutation arm that fails if the order is swapped.
• A composition that skipped a bundle is never cached. A skipped bundle's own files are precisely the ones that cannot be enumerated — its package.json may be the unreadable file. Caching that state would mean never noticing the repair, so a degraded profile composes as shipped until it loads cleanly, then caches again.
• Rows are detached on every path, hit or miss, as the shipped implementation detaches them. A settings form that mutates a returned inherited object must not reach the cache or the next caller. entry itself is deliberately shared — it is a live Loader entry, and rebuilding it would describe a plugin that is not mounted.

maxStaleMs (default 60000) is a ceiling on the one change the stamps cannot see — a rewrite preserving mtimeMs, size and ino. It is not a validation interval; the stamps are checked on every call, inside the window and after it. enabled: false leaves configuration() exactly as shipped without unloading anything, for bisecting a configuration-editing problem in a running app. Unloading the plugin restores configEditor to the shipped object.

On your numbers, and one correction to mine

Your table holds, and it is the arithmetic that made this worth doing. One thing I got wrong in my earlier reply and want to keep visible rather than quietly fix: I wrote that a cache key must watch the profile manifest, the profile patch, each bundle's package.json and each bundle's declared patch files, and that the home patch is not read on this path. The bundle half is right — and it is the half that matters, since ~35 manifests per pass is where your 30,468 reads come from — but "the home patch is not read" was about configuration()'s own composition, and the path around it is not so tidy: edit() calls loadProfileDirectory twice more per save (packages/boot/config-editor/src/index.ts:99 and :136), so a settings write pays two full compositions that this plugin does not cover — they are not configuration() calls.

What is covered is the repeated read of the same unchanged profile, which is what your trace shows.

Where the durable fix belongs

This is a seal applied from outside, and I would rather say so than imply the plugin is the end of it. The durable fix is upstream, in one of two places:

1. memoize inside ConfigEditor#configuration() — the cheapest version is caching the loadProfileDirectory result against the same file identity, which is roughly what this plugin does, but it would serve every consumer of that path rather than only the settings forms, and it would cost one load instead of two; or
2. pass { userLayer: false } where the user layer is not wanted, as readBundlePatches (packages/boot/app-boot/src/profile-context.ts:64) already does — and note that configuration() genuinely needs the user layer, so this is not a fix for this call site, only evidence that the load is known to be expensive.

What the plugin cannot do is make one composition cheap. If a profile is slow for a reason outside the composition — a bundle whose patch file is huge, a js-yaml parse that dominates — the plugin still pays that cost once per window, and the profile itself is where the fix is.

Tests

67 tests, and scripts/inject-defects.mjs rewrites one rule of the source at a time and requires the suite to fail — 36 arms, all currently caught. The mount tests run against a real temporary profile directory, so observe() exercises the shipped loadProfileDirectory rather than a stub of it; the only stand-in is configEditor, whose call count is the number this plugin exists to move. The suite is green on 0.1.7-rc.2, 0.2.0-rc.2 and 0.2.1-alpha.3, with the published peer ranges resolved by npm on each line.

One limit I have not measured: I could not reproduce the 80 s on this machine, so the plugin is verified to stop the repeated composition (that is directly counted in the tests) but not to have moved your wall clock. If you try it, the number worth reporting is the configuration() call count, which debug logging prints with the reason for each recomposition (cold, key-changed, files-changed, too-old).

[likiyoxi]

另一台机器的独立复现（Windows 11 / DSH 0.2.1-rc.2 / 71 个 bundle），确认同一条链路，并补三点上面数据里没有的东西。

1. 放大器：这条链路被「每个活跃会话 × 2 次」调用

在 dsh-capability-panel 场景里，toolkit 每次重扫会为每个 live agent 各调一次 defaultsFor() 和一次 overridesFor()。88 s 的宿主 CDP 采样按函数聚合：read 29.9 s、describe 31.1 s、defaultsFor 14.9 s、overridesFor 14.9 s（后两者是前者的调用方，时间相互重叠）；按调用栈合并后占 non-idle 40.9 s 的 73 %。

也就是说单次 configuration() 的成本在这里不是「启动期 1500 次 × 一次」，而是「活跃会话数 × 2 × 每次工具变更扫描」。3 个会话就是 6 次，一次 0.8–1.0 s，单次 UI 线程冻结立刻到 5–6 s，和你说的 80 s 单核满载是同一段代码的两种表现。

2. 为什么「闭包级缓存」走不通：ctx.get() 每次返回新的 traceable proxy

直接在插件里包一层闭包缓存是无效的 —— 计数器实测 binds=348 / reads=349：349 次读取全部走到绑定重建，缓存一次都没命中。原因是 ctx.get('settings') 返回 traceable proxy，写入落在代理上而不是真实例。必须写到 view[Symbol.for('cordis.original')]（或 ctx.reflect._getImpl(name).value）才留得住 —— 与 @argszero 说的 plugin 写入陷阱是同一件事。

把缓存移到模块级并在 settings/document-updated 里失效之后：reads=349 / hits=347 / describes=2。

3. 同一个设计缺陷还有第二处：pluginManager.listBundles()

listBundles() 同样每次调用同步重解析约 150 个 bundle（无缓存），启动后仍被秒级触发。只修 configuration() 只能解决一半，这条路径需要同样的 memo。

4. A/B（0.2.1-rc.2，Windows 11）

指标	修前	修后
单次动作主线程冻结	7.18 / 4.82 / 6.08 / 6.77 / 14.93 s	1.28 / 1.04 / 1.08 / 0.90 s
窗口无响应累计	34.8 s	约 5.2 s
16 min 窗口主线程停顿占比	27 %	1.9 %
最大事件循环间隔	14,928 ms	1,275 ms

需要说明：这次是「按调用方逐个打补丁」（能力面板模块级缓存 + 一处插件侧漏缓存），不是在 configuration() 上统一做缓存，所以还剩约 1 s 的残余尖峰。

另外两处同类写法（一个每 10 s 重算 peer 依赖、一个冷启动同步遍历 657 个 skill 目录）分别贡献了 12 s 节律冻结和 13 s 冷启动 —— 「无缓存的全量扫描」在这个生态里是会传染的写法，建议文档层面点出来。

关于 @argszero 的 @argszero/dsh-profile-composition-cache@0.1.0

正在 0.2.1-rc.2 上装它做对照。装完会把同样的 A/B 贴回来，重点看两个数：describe() 实际执行次数是否从 349 降到个位数，以及第 3 点里 listBundles() 那条路径是否仍拖慢启动。

[likiyoxi]

装 @argszero/dsh-profile-composition-cache@0.1.0 做了对照，结论是：在这个部署上它一次都没命中，而且比原始实现更慢。原因不在缓存逻辑，而在 stampsHold() 的 ino 判等对 Electron 的 asar 虚拟文件系统不成立。

环境

Windows 11 / DSH 0.2.1-rc.2 打包版（bundle 在 D:\DSH\resources\app.asar 内），profile 64 个 bundle。

同进程 A/B（同一 configEditor 实例，各 3 次）

路径	耗时
instance.configuration()（插件影子）	115 / 118 / 119 ms
ConfigEditor.prototype.configuration.call(instance)（原始实现）	54 / 53 / 65 ms

分解：observe() 里那次 loadProfileDirectory 单独 51 ms，原始实现 62 ms，合计 113 ms —— 与影子路径的 131 ms 吻合。也就是说它每次都在 MISS，而 MISS 的代价是「原始实现 + 一次额外的完整组合」。

为什么永远 MISS

把 stampAll() 的 135 个路径连续采集两次并逐条比较：26 条不一致，全部是 app.asar 内的路径，非 asar 路径零条。不一致的字段只有 ino，mtimeMs 与 size 完全相同：

@deepseek-ai/dsh-base/package.json          ino 5885 → 5911
@deepseek-ai/dsh-base/cordis.patch.yml      ino 5886 → 5912
@deepseek-ai/dsh-web-app/package.json       ino 5887 → 5913

Electron 的 asar 虚拟 fs 每次 stat 给出的 ino 是合成值，不跨调用保持。stampsHold() 在 ino 不等时返回 false，于是命中条件恒不成立 —— 而这个 profile 有 26 个 bundle 位于 archive 内，必然触发。

补充证据：loadProfileDirectory() 返回 skippedBundles = []（64 层全覆盖），entryKey() 两次调用完全一致，所以不是「跳过 bundle 不缓存」或「entry 身份漂移」这两条路径。

建议

不建议简单地「ino 变化就当作未变」——那会把 atomic-rename 的检测一并丢掉。更稳的做法是识别 archive 内的路径（如 .asar 段，或对 Electron 虚拟 fs 做能力探测）时只比 mtimeMs + size：archive 是只读的，其中的文件不可能被 rename 替换，ino 在这类路径上不携带任何信息。

另外，即使 ino 修好，MISS 路径的常量开销也值得压掉：现在一次 MISS 是「原始组合 + 另一次 loadProfileDirectory」，在冷启动 1500 次调用的场景里，只要命中率不是从第一次就接近 100%，这条额外开销会直接叠加。

测完已卸载，等 ino 处理修好后可以立刻重测并回帖。