Skip to content

tracking(perf): bound Desktop and Runtime Host work as history grows #4677

Description

@Astro-Han

Problem

Desktop responsiveness and Runtime Host work should depend on the visible window and the amount of new data, rather than the full Session history. Several paths have violated that constraint: long-session hydration, oversized-Turn rendering, Usage tables, WorkHub linkage reconstruction, and artifact persistence/recovery.

This tracker defines the intended architecture, performance budgets, and remaining delivery work. Individual issues retain their reproductions and detailed reviews. #2913 contains the broader incremental-data-flow design; this issue tracks the measured Desktop and Host outcomes across that work.

Desired outcome

A user can open a long Session, read and scroll while output streams, switch Sessions, and open Usage or WorkHub without full-history work blocking the interaction. Reading position, focus, selection, accessibility, and durable execution semantics remain correct.

Target architecture

flowchart TD
    L[Durable execution and domain records] --> H[Runtime Host: lifecycle and query authority]
    H -->|bounded pages, watermarks and changes| M[Desktop Main: bounded sparse replica]
    M -->|incremental IPC| R[Renderer: bounded visible window]
    R --> S[One transcript scroll authority]
    R --> B[Render boundaries within oversized Turns]
    H --> Q[On-demand WorkHub linkage queries]
    H --> P[Delta persistence and bounded diagnostics]
Loading
  • Runtime Host owns execution. Session/Turn lifecycle and terminal facts remain authoritative there. RuntimeEvent and the appropriate domain ledgers feed read projections; Desktop does not reconstruct execution state from its rendered history.
  • Desktop is an incremental client. Tail bootstrap, bounded pages and generation-checked updates replace full-history loading. Resident data and DOM stay bounded as history grows. One scroll authority owns viewport changes; sub-Turn containment limits rendering work without becoming a second paging or scrolling mechanism.
  • WorkHub reads linkage at its owner. The target Session and Coordination ledger establish current delegation facts on demand. Replace/stop revalidate them under the existing admission boundary. No renderer replay or additional durable active-delegation table is required. The current fix(workhub): resolve WorkHub delegation linkage on demand #4699 lookup still scales with target-local assignment history; its cost must be measured rather than called constant-time.
  • Persistence writes the change. Artifact metadata uses delta writes, and per-call diagnostics store bounded summaries rather than another copy of the conversation. Remaining recovery scans and repeated full metadata reads need a defined consistency/invalidation boundary before optimization.
  • Other views follow the same rule. Usage rows are paged; catalog updates preserve unchanged items; streaming processing consumes new chunks; search and inactive views avoid remote full-history work.

Performance baseline and results

These are measurements or estimates recorded in the linked issues/PRs, not a new benchmark of current main. Each row is a separate workload; the results must not be combined into an overall speedup.

Scenario and source Starting baseline Reported result / remaining gap
Tool-rich 1,000-Turn hydration, 30ms RTT — #2913 About 5,000 sequential requests; 150s theoretical transport lower bound, not a wall-clock measurement Tail bootstrap and byte-bounded paging landed in #2922/#2937. End-to-end latency must be checked against the budgets below.
Hover over an oversized Turn of roughly 15k elements — #4259 Hover p95 59ms; about 20 LoAF >50ms; style recalculation about 1,270ms per measured sweep PR reports 9ms, 0 LoAF >50ms, and about 100ms respectively. This is a hover result, not proof of faster scrolling.
Cold upward scroll, eight 240px wheel steps — #4259 measurement Same-build control with inner containment disabled: 0px worst unexpected anchor movement Old head bfee6e1c: 239.44px, light/dark, three runs each at 1400×900. Later head bd8e0299 changes folded estimates to 32px and uses a 120px test bound; independent remeasurement is outstanding.
Usage Activity log, 409 records — #4531 / #4539 409 rows mounted on each visit Proposed page size: 50 rows. Before/after tab-entry median and p95 are still needed.
Per-call durable data, 600-message conversation and 60 tools — #4722 405,729 B across diagnostic records and capture file 3,944 B after removing the capture and folding diagnostics; same-machine comparison against 780dc4b4.
Cumulative model-call diagnostics over 500 Turns — #4722 193.44 MiB, preparation CPU 607ms 1.88 MiB, 139ms, under the PR's synthetic workload.
Artifact store, 6,000 records / 400 Sessions — #4722 listPage 13.45ms; create 38.32ms 11.54ms / 37.42ms; means of 50 / 20 operations in one run. Full reads and filesystem durability remain significant.
Host cold start, roughly 11.7k artifacts — #4027 / #4037 / #4038 Historical profile: about 130s total, roughly 90s in the artifact metadata/cleanup phase Several persistence changes have landed. A fresh startup profile is required; the historical timing is not the current baseline.
WorkHub linkage lookup — #4699 Opening/reconnecting replayed the Coordination history Current PR reports about 3.8 / 33.8 / 205.3ms for 100 / 1,000 / 6,000 terminal assignments. No comparable before/after wall-clock result is recorded yet.

Target performance

The latency budgets below carry forward the proposed budgets in #2913; they are acceptance targets, not claims that current main meets them.

Scenario Target
Local Session open to visible tail p95 ≤ 150ms
Long Session over 30ms RTT p95 ≤ 800ms, with initial useful tail in one subscription-open round trip
64 MiB Session Tail opens and older history remains pageable; no full-history prerequisite
Normal input, scroll and hover No task/LoAF over 50ms in the fixed interaction trace
Transcript and Sidebar rendering DOM bounded by the resident window/viewport, independent of total history; #2913's initial transcript ceiling is normally 100 Turns
One catalog update with 1,000 Sessions Renderer work ≤ 16ms
256 KiB output arriving in 20-character deltas Cumulative sanitizer CPU ≤ 250ms, preserving cross-delta redaction
Steady-state synchronization and per-call diagnostics Work proportional to changed data; no full conversation copy per call
Cold-scroll geometry No stalled/reversed step or snap to tail. Calibrate the numerical anchor-displacement bound against the control; 120px is not yet an accepted product budget.
Host startup, WorkHub and Usage latency Establish comparable current-main baselines and explicit p95 budgets before accepting these work items. Missing numbers remain open acceptance work.

Implementation plan

Implementation merged and behavior accepted are separate milestones: the checked items above record landed changes, while the open items retain their outstanding acceptance work.

Validation and completion criteria

Run before/after measurements on the same machine, fixture, viewport, theme and motion settings. Record both commits, OS/runtime versions, fixture size, and whether a result is measured, theoretical, or author-reported. Separate cold from warm runs and hover from scrolling. For latency comparisons, use at least 10 repetitions and report median/p95; keep raw traces with the implementation PR.

Use small and oversized Turns, local and 30ms-RTT Sessions, growing WorkHub histories, the 409-record Usage fixture, and the artifact-startup fixture. Exercise actual Electron/CDP interaction where compositor scrolling, focus or startup is relevant. Storybook covers deterministic layout and accessibility; storage microbenchmarks do not establish end-to-end responsiveness.

This tracker is complete when the open work above is resolved, the performance targets are measured on the delivered implementation, and there is no regression in reading position, focus, selection, accessibility, redaction, or durable execution/recovery. Update the result table and work-item checkboxes as changes land; keep review conversations in the linked PRs.

Related work

Prepared with Codex assistance under maintainer direction.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions