Performance: large DSH conversations freeze browser for ~30s (44k DOM nodes / 4.7k SVGs / ~500MB heap)

[SomJsA]

Summary

Opening a large DSH Web conversation freezes Chrome for about 30 seconds, with severe whole-system mouse stutter. This reproduces with hardware acceleration enabled and disabled, so it is not GPU-specific.

Reproduction

1. Serve DSH Web on WSL2 Debian-12, port 3080.
2. Open a conversation that contains a large tool list / session log, for example 可用的工具与继续任务.
3. About 3 seconds after clicking into the conversation, Chrome freezes for roughly 30 seconds.

Measurements (via Chrome DevTools Protocol)

• DOM nodes: 43,939
• SVG elements: 4,681
• HTML size: about 10.5 MB
• JS heap: about 473-485 MB
• Same values with --disable-gpu --disable-gpu-compositing

Impact

The browser main thread is blocked while building and rasterizing this page, and the whole system UI becomes unresponsive for a while.

Suggested fixes

• Virtualize or lazy-render large conversation contents, tool lists, and trajectory rows.
• Collapse tool details by default.
• Cap initial DOM/HTML for old or very large sessions.
• Consider an explicit compact mode when opening large sessions.

Notes

This is not caused by a third-party plugin. It reproduces in a fresh Chrome profile with only DSH Web open.

[setieroth]

+1 — same class of freeze hit on DSH Desktop 2.0.2 (macOS), with a data point from the far end of session size:

• One session grown to 30,000+ events / 8.4 MB zstd transcript / ~660k-token context, with ~23k streaming chunk events pushed over SSE in a single 27-minute turn (AgentTeams captain + 2 members + browser automation on top).
• Pattern: after the window sat idle or right after a long turn ended, the next message send showed nothing for 30s and then failed with signal timed out — the fixed 30s AbortSignal.timeout in dsh-client-connection (see Web UI 发送消息偶发报错 "signal timed out (internal)"：unary RPC 固定 30s 超时且不可配置 #2060). Relaunching the app recovered instantly, every time.
• The host was demonstrably healthy during the freezes: steady 15–20s steps in the session transcript, plus sub-millisecond /api/host.describe probes issued directly against the webserver while a turn was running. So the degradation here is purely client-side: the live conversation view gets progressively heavier as the session grows, until the renderer can no longer settle a fetch within 30s.
• 4 "freeze → relaunch" cycles in a single day, all on this one oversized session; smaller sessions unaffected. So it's not just "opening a big conversation is slow" ([Bug] WebUI 首次加载较长历史对话报「历史加载失败：signal timed out (internal)」 #4403 / [Bug] 大型冷态子代理历史因 30 秒 unary 时限无法加载 #3687 cover the history-load variant) — the live view degrades too.
• Host-side companion gap: the mux FrameQueue in dsh-host-apiproxy is unbounded — a frozen-but-connected consumer turns renderer stalls into unbounded host-side buffering of stream frames. Worth fixing together with virtualization.
• Workaround that held: /compact or fork long-running sessions instead of letting one conversation grow past ~500k tokens.

(AI-assisted comment posted by an agent on behalf of the user; metrics verified against local session logs and host logs.)