perf(desktop): chat selection and deletion become very slow with large chat lists

[0xSolarPunk]

What and why

On desktop, selecting a chat/sidebar row and opening its actions feels very slow. Confirming Delete is also extremely slow before the chat disappears. The behavior feels like UI/main-thread or memory pressure when the workspace contains many dense chats, but the exact split between frontend rendering and backend deletion needs profiling.

Evidence

A 9.28-second screen recording shows:

• delayed sidebar interaction/row action-button selection;
• Delete confirmation appearing, followed by a visibly slow delete completion;
• a dense chat list and large transcript content in the same workspace.

Reproduction

1. Open Garcon desktop with a workspace containing many chats and at least one large transcript.
2. Move across/select chat rows and open the row action menu.
3. Choose Delete and confirm.
4. Measure click-to-menu response and confirm-to-chat-removed response.
5. Repeat with a small workspace or after reducing the loaded transcript size.

Expected

• Chat row selection and action-menu opening respond within one frame / feel immediate.
• Delete removes the chat from the visible registry immediately after the durable registry mutation.
• Heavy provider/native transcript cleanup does not block the user-visible delete response.
• Memory and long-task usage remain bounded as chat count/transcript size grows.

Actual

• Sidebar button/row selection is noticeably delayed.
• Delete confirmation and completion feel extremely slow.
• Suspected large-list/transcript rendering or memory pressure, possibly compounded by synchronous backend/provider cleanup.

Investigation / acceptance criteria

• Capture Chrome Performance trace and heap snapshot while reproducing selection/menu delay.
• Measure chat-list render/update cost, event-handler latency, long tasks, DOM node count, and retained heap by chat count/transcript size.
• Measure DELETE request phases separately: request admission, registry removal/flush, ledger removal, provider transcript release, and response completion.
• Ensure delete response is not blocked by slow provider transcript release once durable deletion intent and registry removal are committed.
• Reduce unnecessary sidebar rerenders and verify virtualization/memoization boundaries for large chat lists.
• Add regression coverage and before/after measurements for both selection latency and delete response latency.
• Verify delete cleanup remains durable/retryable across provider timeout, restart, and failure.

Notes

Do not hide projection duplicates by modifying native Codex/Claude JSONL or carry-over storage. Preserve delete correctness, shares, metadata, project settings, and transcript cleanup semantics while improving responsiveness.

[0xSolarPunk]

Yorozu profiling clarification (related: #626):

• perf(settings): avoid full agent discovery on every app settings read #626 identifies a real but separate workspace-bootstrap/settings bottleneck. It does not explain this issue's deletion or chat multiplexing/switching symptoms.
• Deletion source tracing identified a concrete backend wait: the user-visible delete response awaited provider/native transcript cleanup after durable registry removal. perf(chat): return before provider delete cleanup #576 proposed moving that cleanup to a restart-safe background chain, but the PR was closed without merge, so the fix is not shipped.
• Multiplexing remains unresolved. Ordinary Yorozu switch requests measured about 221–224 ms; one larger 77 KB activation took about 751 ms. The browser capture showed one ~54 ms long task and no sustained main-thread saturation.
• Missing evidence: controlled Yorozu-vs-backtest phase timings, transcript-size-normalized activation measurements, WebSocket/event fan-out, DOM update/render cost, and heap-retention comparison.

Therefore #575 remains the primary tracking issue. Acceptance requires explaining the cross-deployment latency gap separately for deletion and multiplexing, not treating #626 as the root cause.

[0xSolarPunk]

Controlled DevTools follow-up (same client/browser and interaction script; target deployment versus home and backtest comparisons):

Result

The perceived switch/multiplexing delay has two separate components:

1. Transport/edge path dominates baseline latency on the target. Repeated authenticated activation reads measured public TTFB p50 of 590 ms on target versus 72 ms home and 342 ms backtest. The same endpoint measured at each origin was only 7 ms, 11 ms, and 12 ms respectively. Target host CPU/memory/pressure were healthy. This is not target-origin compute saturation.
2. Large/rich transcript activation adds target-specific main-thread jank. Maximum decoded activation payload was 1.71 MB on target versus 198 KB home and 501 KB backtest (8.62x and 3.41x). A rich target switch reached 128 ms click interaction duration, a 100 ms frame, and 349 Svelte microtasks in the trace. Typical click-event p50 remained 24 ms target, 24 ms home, and 28 ms backtest.

What this rules out

• Opening Add to window itself was not slower: 16 ms target, 40 ms home, 16 ms backtest.
• Sidebar population alone is not the explanation: target had 64 chats while backtest had 161.
• Browser heap was comparable (42–52 MB used), with no sustained memory pressure.
• Target and backtest were based on the same public source commit (32c0e718ce9a85f4ed7523944cb2afacd5967c1d), so the measured gap is not explained by that source revision alone.

Code-path implication

Selection starts queue, snapshot, message-activation, and last-selected requests. conversation-session-controller.svelte.ts then loads the activation page into ChatTranscriptCache. The cache retains a fixed message count, not a per-activation byte/complexity budget. Local transcript restore/persistence also uses synchronous localStorage JSON parse/stringify and synchronous cache-index pruning. That synchronous cache path is a plausible amplifier for rich transcripts, but comparison cache sizes were not larger on target, so it is not yet proven as the cross-deployment root cause.

Proposed acceptance criteria

• Add phase timing/Server-Timing for activation fetch, JSON decode, cache apply, Svelte flush, Markdown render, and next paint.
• Bound initial activation by bytes/characters as well as message count; avoid returning/rendering a multi-megabyte 50-message page synchronously.
• Move large transcript cache serialization/restore off synchronous localStorage (or defer it outside interaction-critical work).
• Add a browser regression using a 1+ MB rich transcript: warm switch p95 interaction under 50 ms, no task/frame over 50 ms, while preserving pagination and bottom restoration.
• Keep transport latency and frontend rendering as separate measurements; infrastructure routing can explain baseline delay but not the rich-transcript main-thread spike.

Deletion remains the separate backend wait already described above: provider/native release still gates the response because #576 was not merged.

Sensitive deployment identifiers, addresses, credentials, chat IDs/titles, and private paths omitted.