Reduce dashboard network waiting and show the TUI shell promptly

#35 · open · 0 comments

View on GitHub ↗

damacus

The standalone dashboard requests status, statistics and tasks sequentially. On a loopback HTTP/1.1 fixture with an empty task list and 50 ms server delay per request, it measured 176.54 ms median and 187.45 ms p95 across 15 runs. TUI construction also waits for status/tasks before entering the screen. ## Scope Remove redundant work first, then consider bounded overlap of independent reads using existing facilities. Render the TUI shell while optional data loads. Preserve complete standalone dashboard payloads and authentication/error handling. Sources: src/services.rs operational_overview/dashboard and src/main.rs run_interactive. ## Passing bar - Standalone dashboard p95 <=100 ms on the same three-request, 50 ms fixture, at least 40% below baseline. - TUI first shell frame p95 <50 ms while optional requests take 500 ms; establish the current first-frame baseline. - Verify delayed, failed, forbidden and multi-page responses without dropping output or hiding errors. - Bounded workers and shutdown; no async runtime rewrite or new runtime dependency. - Measure at 0/50/150 ms delays, with at least 30 samples per case before acceptance. ## Evidence and acceptance Baseline: commit ffd29e3, macOS arm64, release build, Rust 1.97.1, assessed 5 September 2026. These are local measurements, not production guarantees. Compare before/after with locked dependencies on the same machine in at least three interleaved batches. Keep timing checks out of shared-runner CI; test deterministic behaviour there. Preserve JSON, terminal output meaning and errors. Avoid new runtime dependencies. Reject unexplained CPU/RSS growth over 5% or executable growth over 1%.

Comments