perf(startup): continue reducing desktop startup and interactive shell readiness time

[limityan]

Current Global Status

Last updated: 2026-06-01

Feature goal: reduce desktop cold-start, first visible shell, and interactive_shell_ready time without hiding existing navigation/session content or sacrificing existing behavior. Optimization is judged by end-to-end user scenarios, not isolated code movement.

Current headline:

• The issue remains open. The latest strict release-fast A/B data shows interactive_shell_ready is now measurably lower in perf(startup): add tracing and reduce shell latency #1015, but post-interactive startup pressure and first-interaction consistency still need follow-up.
• The most important current bottleneck signal is frontend/bridge queue pressure, not backend command body time. New trace data from perf(startup): add tracing and reduce shell latency #1015 shows pre-interactive command body time around 3.0 ms p50, while estimated bridge/queue wait is around 521.1 ms p50.
• Long historical session behavior remains latest-content-first with 3 / 80 turns initially loaded in the generated fixture. Comparable restore/hydrate metrics are neutral to positive, while full background hydrate has a small +2.2 ms p50 regression that should remain tracked.

Global Optimization Scoreboard

Performance PR acceptance rule:

• Every performance PR must include repeated A/B timing data for the target business scenario and any materially affected user-facing scenario.
• If work is deferred from startup to a later interaction, that later interaction must be measured. Bundle size alone is supporting evidence, not an accepted user-perceived performance result.
• If one scenario improves while another regresses, the regression must be listed with severity. Material UX regressions require product confirmation before the PR is considered an effective optimization.
• PR descriptions must list measured wins, measured regressions, test method, risk/functional impact, and unresolved data gaps.

PR	Status	Target scenario	Key result data	Known regression / risk	Decision state
#934	Merged	Release-fast cold startup / first visible shell	main_window_shown p50 1504.7 ms -> 1101.8 ms, -402.9 ms (-26.8%); start_application_end p50 1455.7 ms -> 1035.6 ms, -420.1 ms (-28.9%)	interactive_shell_ready p50 1538.9 ms -> 1628.4 ms, +89.4 ms (+5.8%)	Merged, but interactive readiness remained unresolved
#958	Merged	First open of larger historical sessions	Backend first restore avg 69.8 ms -> 5.1 ms, about -92.7% before first render	Deferred full hydrate still costs 35.1-99.5 ms after latest-content rendering	Merged, latest-content-first tradeoff accepted
#971	Merged	Startup by deferring editor and root AI startup paths; first editor-heavy interactions protected by post-splash idle warmup	Pre-merge head p50: first_script_eval -577.9 ms (-49.0%), main_window_shown -598.2 ms (-45.7%), interactive_shell_ready -660.6 ms (-38.4%); first code editor -176.7 ms (-46.0%), first Git diff -127.4 ms (-32.0%) in explicit-warmup path	Latest-main strict A/B was not rerun before merge; editor warmup consumes about 230 ms idle time; users clicking before warmup finishes can still pay partial cold cost	Merged; issue stayed open for post-merge main baseline and continued interactive_shell_ready work
#1015	Open	Latest-main strict release-fast cold startup plus generated long-session first open	Current main@2a016364 -> #1015 p50: first_script_eval 632.4 -> 545.6 ms (-13.7%); main_window_shown 740.0 -> 593.4 ms (-19.8%); interactive_shell_ready 1138.7 -> 778.4 ms (-31.6%); non_critical_init_done 1421.2 -> 1296.3 ms (-8.8%)	Long-session fullHydrateDuration p50 33.8 -> 36.0 ms, +2.2 ms (+6.5%); AppLayout is now a lazy chunk; remaining bridge/import pressure is still visible	Open; acceptable based on latest A/B if CI stays green, but issue remains open for the next PR scopes below

Latest Comparable Snapshot

Method: Windows desktop release-fast, 5 cold launches each. Baseline is gcwing/main@2a016364; latest measured head is #1015 85225a72.

Scenario	Metric	Main p50	Latest head p50	Delta
Cold startup	first_script_eval	632.4 ms	545.6 ms	-86.8 ms (-13.7%)
Cold startup	main_window_shown	740.0 ms	593.4 ms	-146.6 ms (-19.8%)
Cold startup	interactive_shell_ready	1138.7 ms	778.4 ms	-360.3 ms (-31.6%)
Cold startup	non_critical_init_done	1421.2 ms	1296.3 ms	-124.9 ms (-8.8%)
Long session first open	restoreDuration	53.8 ms	47.6 ms	-6.2 ms (-11.5%)
Long session first open	hydrateDuration	123.6 ms	109.8 ms	-13.8 ms (-11.2%)
Long session first open	latestFrameSinceHydrate	43.2 ms	42.5 ms	-0.7 ms (-1.6%)
Long session background hydrate	fullHydrateDuration	33.8 ms	36.0 ms	+2.2 ms (+6.5%)

Global Conclusions

• Earlier attempts failed to move end-to-end startup when they optimized narrow local slices or moved work without measuring the receiving stage. The current tracking rule is therefore end-to-end first, with local slices used only to explain the result.
• Backend command body time is currently not the primary pre-interactive blocker. The latest trace points to frontend module graph, command scheduling, and WebView bridge/queue pressure as the higher-leverage targets.
• Startup and session work should not be optimized by hiding product content. Existing visible workspace/session navigation must remain available unless an explicit product decision says otherwise.
• Long-session first-open needs a stricter user-perceived target: latest visible content should appear as close to 100 ms as possible, while full history hydration can continue in the background with clear safeguards.

Remaining PR-Sized Work

Scope	Goal	Required data before merge	Decision / risk
PR-A: post-interactive session metadata pressure	Coalesce/dedupe initial list_persisted_sessions_page, load only visible/expanded metadata, and add loading feedback for explicit show-more	Startup + first show-more timing; session list correctness; command count before/after	Must not hide currently clickable sessions or make show-more feel stalled
PR-B: git/workspace status batching	Batch/cache git_is_repository, git_get_repository_basic, and workspace status probes per workspace path	Startup and post-interactive command breakdown; workspace switch timing	Remote workspace behavior must be preserved; remote deferral needs explicit confirmation
PR-C: bootstrap config/keybinding path	Replace repeated early get_config calls with typed bootstrap/cache where safe; keep global shortcuts correct	Startup A/B plus settings/keybinding first-use timing	app.keybindings should not be deferred blindly because it affects global UX
PR-D: frontend bundle/import graph cleanup	Resolve static/dynamic import conflicts for FlowChatManager/state machine, ConfigManager, MCP/ACP, context menu, and terminal/editor surfaces	Root chunk size plus startup E2E; first-use timings for moved surfaces	Moving modules without first-use data is not sufficient
PR-E: long-session latest-frame target	Reduce generated long-session clickToLatestFrame toward <=100 ms via render scheduling/viewport-priority hydration	Long-session fixture and at least one real large-session sample, latest frame and full hydrate	Full hydrate can be deferred, but scroll/search/history behavior must remain correct
PR-F: native/WebView startup slice	Investigate webviewBuildDuration and the 150 ms show wait without reintroducing splash flicker or black/white logo transitions	Video/screenshot sanity plus release-fast startup A/B	Any flicker risk requires product confirmation before changing show timing
PR-G: measurement harness hardening	Make strict A/B report generation easier and avoid noisy production logs	Harness output and CI/local command documentation	Measurement-only PRs should not claim product performance wins

Required Metrics For Next Startup Stage

Scenario	Required comparison	Acceptance note
Cold startup to first visible shell	Latest main vs PR, repeated Windows release-fast cold launches	Must improve or be neutral with data.
Cold startup to interactive_shell_ready	Latest main vs PR, repeated Windows release-fast cold launches	Regressions need explicit confirmation.
First open of long historical session	Latest main vs PR, long-session fixture and real local sample if available	Latest visible turns must render first; total hydrate cost must be reported.
First code editor open	Latest main vs PR, first-use timing after fresh startup	Required for any PR that defers Monaco/editor work.
First Git diff editor open	Latest main vs PR, first-use timing after fresh startup	Required for any PR that lazy-loads diff editor paths.

Follow-Up Metrics From PR #971

Related PR: #971

Benchmark method: Windows desktop release-fast. PR #971 was merged on 2026-05-30 as merge commit 065cd8db; the measured pre-merge head was 20d6a235, rebased on gcwing/main@18aa2df4. The comparison baseline remains #949's continuity baseline gcwing/main@978e079f; latest-main strict A/B was not rerun before merge. Startup and long-session data uses tests/e2e/specs/performance/startup-session-perf.spec.ts; editor first-open data uses tests/e2e/specs/performance/editor-first-open-perf.spec.ts. Editor timing measures app event trigger to Monaco DOM ready to isolate deferred editor/rendering cost.

PR #971 Business Scenario Coverage

Business scenario	Baseline p50	PR #971 p50	Delta	Decision impact
Cold startup first_script_eval	1179.0 ms	601.1 ms	-577.9 ms (-49.0%)	Positive startup result.
Cold startup main_window_shown	1309.5 ms	711.3 ms	-598.2 ms (-45.7%)	Positive first-shell result.
Cold startup interactive_shell_ready	1720.4 ms	1059.8 ms	-660.6 ms (-38.4%)	Positive readiness result in current head data; issue remains open for deeper interactive_shell_ready optimization.
Non-critical initialization completion	1667.2 ms	1315.9 ms	-351.3 ms (-21.1%)	Positive in this run despite deferred scheduling.
First open of generated long session, backend restore	45.6 ms	41.5 ms	-4.1 ms (-9.0%)	Neutral to positive.
First open of generated long session, latest frame	45.7 ms	46.5 ms	+0.8 ms (+1.8%)	Small regression, below material UX threshold in this run.
First open of generated long session, initial hydrate	105.9 ms	102.9 ms	-3.0 ms (-2.8%)	Neutral to positive.
First open of generated long session, full hydrate	51.5 ms	52.7 ms	+1.2 ms (+2.3%)	Small regression, track only.
First code editor open, no explicit warmup wait	384.1 ms	207.4 ms	-176.7 ms (-46.0%)	Previous PR regression mitigated.
First code editor open, explicit warmup wait	384.1 ms	203.4 ms	-180.7 ms (-47.0%)	Positive first-use result after idle warmup.
First Git diff editor open, no explicit warmup wait	398.6 ms	283.7 ms	-114.9 ms (-28.8%)	Previous PR regression mitigated.
First Git diff editor open, explicit warmup wait	398.6 ms	271.2 ms	-127.4 ms (-32.0%)	Positive first-use result after idle warmup.

PR #971 Notes

• The earlier first-use editor regression is now mitigated in current release-fast measurements: code-editor p50 improved from the previous PR measurement of 503.7 ms to 207.4 ms without explicit wait, and Git-diff p50 improved from 526.9 ms to 283.7 ms without explicit wait.
• Background editor warmup duration p50 is about 226.7-237.0 ms across the measured editor scenarios. It is scheduled only after splash exit, uses low-priority idle scheduling, and yields between editor-surface preload stages, Monaco init, and theme sync.
• The current no-wait editor measurements all had editor_startup_warmup_end before the trigger. That means the measured common path is good, but a user who clicks an editor immediately after splash exit can still see partial cold cost.
• Startup splash behavior changed from immediate loading text to logo-only first. Loading workspace... appears below the logo only after 1800 ms if workspace loading is still active, so normal startup does not show a short text flash.
• Current state: PR perf(startup): defer editor and AI initialization #971 is merged. The next stage must use post-merge main as the new baseline and keep this issue open for interactive_shell_ready analysis and residual-risk validation.

Required Metrics For Next Startup Stage

Scenario	Required comparison	Acceptance note
Cold startup to first visible shell	Latest main vs PR, repeated Windows release-fast cold launches	Must improve or be neutral with data.
Cold startup to interactive_shell_ready	Latest main vs PR, repeated Windows release-fast cold launches	Regressions need explicit confirmation.
First open of long historical session	Latest main vs PR, long-session fixture and real local sample if available	Latest visible turns must render first; total hydrate cost must be reported.
First code editor open	Latest main vs PR, first-use timing after fresh startup	Required for any PR that defers Monaco/editor work.
First Git diff editor open	Latest main vs PR, first-use timing after fresh startup	Required for any PR that lazy-loads diff editor paths.

Feature Goal

Reduce overall desktop cold-start time and first-screen wait time without hiding existing navigation content or sacrificing feature behavior. Performance work should improve the time to a usable shell, not only move work out of one metric.

Original Problem

Cold startup currently pays for too much work before or around the first visible shell:

• Startup eagerly loads systems that are not always needed before first interaction, including IDE / MCP / ACP startup probes and MiniApp catalog refresh.
• Session navigation previously loaded far more session metadata than was immediately visible or clickable.
• The startup path showed a black-background logo and then a white-background logo before the main UI, causing a visible flash.
• Earlier measurements showed that improving isolated marks is not enough: interactive_shell_ready still needs direct follow-up work.

Related Stage 1 PR

Related PR: #934

This issue should remain open after #934 is merged. PR #934 is the stage-1 first-screen optimization and does not complete the broader startup performance goal.

Stage 1 Performance Metrics From PR #934

Benchmark method: Windows desktop release-fast cold launches, 10 runs per build, p50 comparison using the same packaged WebView path.

P50 metric	Baseline	Stage 1 PR	Delta
main_window_shown	1504.7 ms	1101.8 ms	-402.9 ms (-26.8%)
start_application_end	1455.7 ms	1035.6 ms	-420.1 ms (-28.9%)
startApplicationDurationMs	614.7 ms	27.7 ms	-586.9 ms (-95.5%)
afterRenderDurationMs	584.1 ms	461.4 ms	-122.7 ms (-21.0%)
Primary startup API count	15.5	7.0	-8.5 (-54.8%)
Primary startup response bytes	12,891	7,699	-5,192 (-40.3%)
Session metadata loaded	187	27	-160 (-85.6%)
Max session metadata duration	175.1 ms	53.3 ms	-121.8 ms (-69.6%)
interactive_shell_ready	1538.9 ms	1628.4 ms	+89.4 ms (+5.8%)

Additional PR #934 backend microbenchmark: paged session metadata for 1000 sessions reports about page5_avg_ms=11.550 versus full_list_avg_ms=88.142, about 7.6x faster for the paged backend path.

Stage 1 Scope Already Covered By PR #934

• Show the native desktop main window earlier while keeping the frontend show path as a fallback.
• Defer non-critical IDE / MCP / ACP / MiniApp startup work behind first visible shell or idle boundaries.
• Page session metadata so startup fetches only initially visible rows, while explicit show-more loads the next page with loading feedback.
• Keep workspace and session sections visually expanded by default instead of hiding existing navigation content to obtain the win.
• Remove the extra pre-React static logo layer to avoid the double-logo flash.
• Keep editor and LSP startup lazy, with a first-open loading prompt for the editor initialization path.

Remaining Follow-Up Work

• Directly optimize interactive_shell_ready; this is the main remaining blocker because PR perf(startup): reduce desktop first-screen work #934 improves first-visible metrics but regresses this readiness mark by about 89 ms p50.
• Profile React mount and first-shell effects to identify long tasks, synchronous store hydration, expensive render paths, and readiness gating that still run before the shell is actually usable.
• Revisit startup marks so first-visible, first-interactive, and deferred-work completion are clearly separated and comparable across strict A/B runs.
• Add or refine measurements for the first on-demand cost of deferred ACP / IDE / MCP / LSP work, especially editor first-open and agent flows that require language-service indexing.
• Validate future stages with strict cold-start A/B data on the latest main before merging.

Constraints

• Do not trade away visible functionality or default navigation behavior for startup metrics without explicit product confirmation.
• Lazy loading is acceptable only when the user gets clear loading feedback for actions that can exceed about 1 second.
• LSP base configuration can be prepared cheaply, but language servers and indexing should start only when the editor or an agent flow actually requires language services.
• Future PRs should update this issue with the same metric table style so the trend is visible over time.

Follow-Up Metrics From PR #958

Related PR: #958

Benchmark method: Windows desktop debug preview for startup/session-list observations, plus real persistence restore-path measurements on the 5 largest local sessions by turn count. The restore benchmark compares the pre-PR full restore behavior with PR #958's tailTurnCount=3 first restore, then explicitly records that full history is still hydrated later in the background.

PR #958 Business Scenario Coverage

Business scenario	Baseline / reference behavior	PR #958 result	Product impact
Debug startup to visible native window	Existing native show path	Main window show at 944 ms after main-window create start	No latency win claimed; unsafe delayed-window strategy was removed.
Debug startup to frontend script	Existing Vite/WebView cold module path	first_script_eval at 9799.4 ms	Still slow; static preload only reduces blank-screen perception.
Debug startup to shell readiness	Existing readiness path	interactive_shell_ready at 10557 ms	Still open follow-up work for this issue.
Startup workspace/session navigation APIs	Existing paged metadata path	get_opened_workspaces 15.1 ms, get_recent_workspaces 13.9 ms, 7 list_persisted_sessions_page calls max 14.6 ms	Confirms workspace/history list remains visible and responsive.
First open of small/current session	Full restore is effectively unavoidable	1/1 turn restored in 133.4 ms, convert 1.0 ms, state commit 0.5 ms	Neutral; no tail-load benefit for short sessions.
First open of larger historical sessions	Full history read before first render	Tail-3 first restore reads only latest turns, then full history hydrates after 150 ms if state is unchanged	Improves time to latest visible conversation, while preserving eventual full history.
Completed large model round rendering	Previously rendered from oldest visible groups first	Completed rounds render newest visible groups first; streaming rounds remain head-anchored	Improves perceived latest-content priority; unit-test covered, no separate browser timing claimed.

PR #958 Historical Session Restore Measurements

Local sample	Turns	Size	Baseline full restore avg	PR first restore avg (tail=3)	Deferred full hydrate cost still paid	Turn files avoided before first render
A	26	3.02 MB	75.5 ms	4.2 ms	75.5 ms	23
B	23	4.29 MB	99.5 ms	5.8 ms	99.5 ms	20
C	17	1.33 MB	35.1 ms	2.4 ms	35.1 ms	14
D	14	2.95 MB	59.3 ms	2.9 ms	59.3 ms	11
E	11	3.80 MB	79.7 ms	10.0 ms	79.7 ms	8

Summary:

• Baseline full restore avg range: 35.1-99.5 ms.
• PR first restore avg range: 2.4-10.0 ms.
• Average initial backend restore reduction across these samples: 69.8 ms to 5.1 ms, about 92.7% lower before first render.
• Full-history hydration still costs 35.1-99.5 ms after the 150 ms delay; PR perf(flow-chat): render recent session history first #958 moves that work behind latest-content rendering rather than eliminating it.
• Startup interactive_shell_ready remains unresolved and should continue to be tracked by this issue.

[limityan]

Follow-up PR #953 addresses the historical-session open issues found during the startup investigation:

• Caps completed historical model-round first render to 80 groups, then appends 80 groups every 16ms.
• Fixes TodoWrite duplicate keys from restored legacy/truncated ids.
• Replaces internal session-view truncation markers with user-facing preview text.
• Fixes the usage-card Tooltip ref warning.

Diagnostic data used for this PR:

• Problem logs showed 156 and 263 duplicate-key warnings keyed by [truncated for session view], with the stack rooted in TodoWriteDisplay.
• For a 263-group class of case, the first render is bounded to 80 groups instead of all 263 groups, a 69.6% reduction in initial group render volume.
• Local debug logs after the duplicate-key/truncation-path fixes showed duplicate-key warnings and legacy truncation marker logs reduced to 0.

This does not close the issue. The remaining follow-up is still direct optimization of interactive_shell_ready and related startup readiness costs.

[limityan]

Update from #966:

This PR adds the release-fast startup/session performance harness and records the latest post-rebase sample for the follow-up optimization work. The issue should remain open after #966 because it does not claim an end-to-end startup reduction; it makes the current slices measurable and fixes the visible startup splash background mismatch.

Latest release-fast sample:

Scenario	Metric	Result
Startup	interactive_shell_ready	1943.5 ms
Startup	main_window_shown	1484.6 ms
Startup	non_critical_init_done	1886.8 ms
Long session first open	initially loaded turns	3 / 80
Long session first open	latest-turn first frame	48.9 ms
Long session background hydrate	full hydrate	56.5 ms

Startup API hot spots in the same sample:

Command	Count	Total	Max
get_config	10	1438.7 ms	357.5 ms
initialize_ai	1	335.9 ms	335.9 ms
git_is_repository	4	73.3 ms	28.7 ms
remote_get_workspace_info	1	69.5 ms	69.5 ms
git_get_repository_basic	3	51.8 ms	17.8 ms

Follow-up candidates to keep tracking here:

• Collapse or cache duplicate startup get_config reads, then validate whether interactive_shell_ready and non_critical_init_done move down.
• Defer initialize_ai until the first agent/model action that actually needs it, or split cheap config validation from expensive provider/client setup.
• Investigate native WebView create/show/page-load slices separately from frontend app readiness. The latest run still spent about 838 ms in main-window create/show before frontend milestones.
• Keep long-session first-frame below the 100 ms target while separately optimizing cold background full hydrate for very large raw tool-result payloads.

[limityan]

Update from PR #971 (perf(startup): defer editor and AI initialization):

• Deferred Monaco loader/CSS/worker setup to first editor initialization.
• Lazy-loaded editor panel implementations from FlexiblePanel.
• Moved non-critical tool/context-menu initialization to bitfun:interactive-shell-ready with a 10s fallback.
• Removed root App AI auto-initialization and narrowed startup-visible barrel imports.

Measured with pnpm --dir src/web-ui run build:

Scenario	Entry JS	Monaco runtime markers	Root AI hook marker
gcwing/main@978e079f	8,298,942 bytes	present	present
PR #971 (de70290e)	4,294,378 bytes	removed	removed

Entry JS reduction: 4,004,564 bytes / 48.25%.

Remaining follow-up: run repeated release-fast cold-start E2E after merge and continue reducing shared API/config barrels so unrelated API modules such as the initialize_ai command wrapper no longer appear in the first shell bundle.

[limityan]

Update from PR #1015 (perf(startup): add tracing and reduce shell latency):

This PR adds P0 observability plus a focused P1/P2 startup reduction. It does not close this issue; it establishes finer-grained timing and reduces the current latest-main startup path.

Strict A/B method: Windows desktop release-fast, 5 cold launches each. Baseline is gcwing/main@2a016364; PR head is 85225a72 rebased on that baseline.

Scenario	Metric	Main p50	PR p50	Delta
Cold startup	first_script_eval	632.4 ms	545.6 ms	-86.8 ms (-13.7%)
Cold startup	main_window_shown	740.0 ms	593.4 ms	-146.6 ms (-19.8%)
Cold startup	interactive_shell_ready	1138.7 ms	778.4 ms	-360.3 ms (-31.6%)
Cold startup	non_critical_init_done	1421.2 ms	1296.3 ms	-124.9 ms (-8.8%)
Long session first open	restoreDuration	53.8 ms	47.6 ms	-6.2 ms (-11.5%)
Long session first open	hydrateDuration	123.6 ms	109.8 ms	-13.8 ms (-11.2%)
Long session first open	latestFrameSinceHydrate	43.2 ms	42.5 ms	-0.7 ms (-1.6%)
Long session background hydrate	fullHydrateDuration	33.8 ms	36.0 ms	+2.2 ms (+6.5%)

New PR-only diagnostic fields now available for future stages:

Diagnostic	PR p50
webviewBuildDuration	500.0 ms
mainWindowShownToInteractive	183.7 ms
workspaceInit	73.6 ms
pre-interactive command count	12
pre-interactive command frontend total	524.1 ms
pre-interactive command backend body total	3.0 ms
pre-interactive estimated bridge/queue total	521.1 ms
pre-interactive get_config count	3
pre-interactive get_config frontend total	295.8 ms
long-session clickToLatestFrame	166.1 ms
long-session clickToFullHydrateFrame	360.8 ms

Main implementation points:

• Native/frontend startup trace now covers WebView/window timing, frontend readiness, Tauri command body/queue estimates, workspace initialization, and long-session first-open timing.
• AppLayout is lazy-loaded and the startup overlay waits for layout readiness before handoff to avoid blank/flicker risk.
• AI experience/model config reads no longer happen at import/constructor time; non-critical config/update/announcement work moves behind shell readiness.
• Workspace initialization overlaps independent identity/global-state work while preserving state publication order.

Known risks and follow-up:

• The small fullHydrateDuration p50 regression is explicitly tracked but below a material UX threshold in this run.
• The new trace shows bridge/queue wait dominates backend command body time; the next stages should target session metadata pressure, git/workspace status batching, config/keybinding bootstrap, and remaining frontend import graph conflicts.
• app.keybindings and remote workspace info were intentionally not deferred here because they affect global shortcuts and remote correctness.