Repository navigation
Daemon follow-up (conditional): incremental transcript tail parsing / provider worker pool #20
Closed as not planned
Description
Conditional follow-up from #14 (delivery step 5). Do not start without a profile attached: the epic explicitly defers this unless the step-4 benchmark still shows transcript scanning or provider contention as a meaningful bottleneck.
Scope candidates (pick only what the profile warrants)
- Incremental transcript tail parsing in
src/utils/jsonl-metrics.ts: append-only tail reads keyed by canonical file identity; must handle truncation, replacement, compaction and partial trailing records (build on the invalidation tests from the providers/caches issue). - Bounded provider worker pool: only if async scheduling on the main loop measurably contends.
Non-goals
Anything else from the epic. Cache-first + validated whole-analysis reuse is expected to be sufficient; this issue exists so the surplus is tracked, not scheduled.
Оценка
- LOC: ~0–300
- Размер: S/M
- Время (код): ~10–50 мин
- Время (review): ~10–25 мин
- Время (итого): ~20–75 мин
Priority: low (conditional).
Activity
axisrow commentedon Sep 30, 2026
Conditional follow-up triage: data says not-needed
Measured against the PR #50 acceptance run (
docs/daemon-19-results.json,docs/daemon-19-bench.md,docs/daemon-19-verification.md, merged at 597f94c; Apple M5, ambient loadavg 4–15, so latency figures are upper bounds):Epic gate status. Gate: ≥50% aggregate-CPU reduction, warmed 36-session workload, daemon + clients included. Measured 180.0 → 34.7 ms CPU/render = 80.7% reduction (38.88 → 7.50 CPU-s total): PASS. Warm shared-mode steady state is 16.9–46.8 ms CPU/render across all passing scenarios (one-shot 118–250 ms), with output hashes identical to one-shot in every comparison row.
Incremental transcript tail parsing — not justified.
src/utils/jsonl-metrics.ts(revalidateTranscriptAnalysisCache). A warm render does not rescan an unchanged transcript at all; tail parsing would only touch the already-changed-file path.Bounded provider worker pool — not justified.
hashes=1up to 50 sessions.MAX_IN_FLIGHT_RENDERS = 4+ the client's ~8 s retry ladder → some 503 busy). That is neither transcript scanning nor git/provider scheduling: a worker pool does not remove a deliberate 400 ms uncached command. The verification doc records the explicit decision not to tune limits to the benchmark. Latency tails at 50 sessions (p99 up to ~3.9 s) grow with the busy-retry ladder by design and under ambient load — not from provider scheduling.Recommendation: keep the current cache-first + validated whole-analysis path; close this as not-needed. Revisit only if a future profile shows (a) the changed-transcript rescan of very large transcripts among the top render-cost items, or (b) renders dropped under contention (
busy503s) in a scenario with no slow widget involved. Numbers to re-check then: s50-shared-warm-large CPU/render and the daemonbusy-vs-okcounter ratio.axisrow commentedon Sep 30, 2026
Closing as not-needed: the PR #50 acceptance data shows no transcript-scan or provider-contention bottleneck (80.7% CPU reduction at the gate; warm shared renders 16.9-46.8 ms CPU/render). Analysis and numbers above.