[Bug] Desktop 0.2.0-rc.2 on Windows: renderer keeps one CPU core busy (60-130%) while the client is idle; input lags

[zuojinxin]

Note — this report is the outcome of the user hitting the slowdown live and asking DeepSeek V4.1 Flash (deepseek-v4.1-flash, running inside DSH itself) to investigate it. The measurements below, the thread-level breakdown and the code reference all come from that investigation; the user reviewed the report before posting.

同一症状已有人报过（见文末 Related reports 的 #9617）；这条补充的是量化测量 + 已定位到的代码路径。

Summary

The desktop client's renderer process keeps one CPU core busy the entire time the window is open — 60–130 %, with bursts above 100 % — including while the session is completely idle: no input, no streaming, no agent activity. Typing into the composer is visibly delayed (every keystroke hitches), while every other application on the same machine stays responsive with normal CPU usage.

• The heavy process is the renderer, not the main/host process and not the GPU process.
• The load does not follow the agent turn — it is still there after a turn finishes.
• Restarting the client clears it for a while.
• Once, the client showed the bottom-left “reconnecting” indicator; when it reconnected, the renderer dropped from ~135 % to ~34 % within a few seconds (the client UI state was rebuilt) and then grew again during normal use.

Reproduction

1. Launch DeepSeek Harness (desktop, Windows 11).
2. Resume a session whose transcript is fairly large (~1000 records; a handful of tool results above 100 KB).
3. Do not touch the client for 10+ minutes (no clicks, no typing, no agent activity).
4. Watch the renderer process in Task Manager.

A narrower reproduction for the per-frame loop described below:

1. Open any anchored menu that uses the @deepseek-ai/dsh-client-ui-primitives menu component.
2. DevTools → Performance → record 5 s without touching anything.
3. The main thread shows a continuous per-frame place() doing forced layout on every frame.
4. Close the menu → the loop stops immediately.

Current behavior

Measurement (idle)	Value
Renderer process CPU	28–135 % of one core; never below 28 % across a 65-minute window
GPU process CPU	0–32 %
Main / host process CPU	0.5–1.8 %
Thread-level sample (5 s)	one JS/main thread at 68.8 %; compositor and raster threads 0.3–2.5 %
Memory	590–880 MB, mild oscillation, no monotonic growth
Cumulative	renderer 2470 CPU-seconds over 65 minutes of uptime (≈ 63 % average)

Thread level matters here: the busy thread is the renderer's main (JS) thread while the compositor/raster threads are essentially idle — JavaScript plus forced layout, not continuous painting. File watching, disk I/O and the host process were ruled out (host stayed under 2 %, no background jobs were running).

Suspected code path (present in the shipped bundle)

While a portaled anchored menu is open, the menu's position tracker re-schedules itself on every animation frame and re-measures on every frame — @deepseek-ai/dsh-client-ui-primitives (the same component is inlined in the @deepseek-ai/dsh-web-frontend bundle):

const place = () => { /* getBoundingClientRect() + offsetWidth/offsetHeight reads, then setState */ };
place();
const track = () => { place(); frame = requestAnimationFrame(track); };
let frame = requestAnimationFrame(track);
window.addEventListener("scroll", place, true);
window.addEventListener("resize", place);
return () => { cancelAnimationFrame(frame); /* … */ };

If such a menu stays mounted with open: true — including a menu that is no longer visible — the frame loop never stops and forces a layout on every frame. That matches the thread profile above, and it explains why rebuilding the client state (the reconnect) dropped the load almost immediately.

Expected behavior

Renderer near idle when nothing is happening (a few percent at most), and typing without delay.

Environment

• DSH: @deepseek-ai/dsh-desktop 0.2.0-rc.2
• Runtime: Electron 44.0.0, Node 24.18.1
• OS: Windows 11 Pro, build 22631, x64; locale zh-CN
• Profile: desktop, 23 client plugins enabled (all from the plugin market; the same set has been stable for weeks, nothing added or removed in this window)

Related reports

• [问题] CPU、内存与GPU占用高 #9617 — [问题] CPU、内存与GPU占用高 (same symptom: high usage on 0.2.0-rc.2 / Windows 11 even when nothing is running)
• Desktop: scroll sampling forces repeated synchronous layout on long conversations #8291 — Desktop: scroll sampling forces repeated synchronous layout on long conversations (related class: repeated synchronous layout)
• [Bug] 大会话下拖动滚动条 / 分栏手柄，浏览器主进程单线程 100% 自旋，页面长时间失去响应 #7131 — 大会话下拖动滚动条 / 分栏手柄，浏览器主进程单线程 100% 自旋 (related class: single-thread spin)