Performance Audit
This audit is evidence-first. The extension does not collect performance telemetry. Measurements are local benchmark output or manually captured browser traces that contain no prompt, response, page, file, or credential data.
Current scope
Section titled “Current scope”| Item | Question | Current decision |
|---|---|---|
| PERF-07 | Does per-token stream reduction or session-state publication create measurable cost? | Keep reducer/session-state ownership unchanged; retain the benchmark evidence without an unsupported refactor. |
| PERF-02 | Can search results survive page/worker recreation without stale results? | Keep results in memory; retain them with bounded insertion order until a vector-generation invalidation contract exists. |
| PERF-10 | Does the fixed inter-batch wait materially delay ingestion or retrieval? | Yield between batches with no fixed wall-clock delay; provider adapters remain responsible for throttling. |
Reproduce
Section titled “Reproduce”Run:
pnpm benchmark:performanceThe command reports reducer CPU timing, cache-pruning timing, and the modeled inter-batch wait for representative batch sizes. It is a guard against making claims from a single trace; compare repeated runs on the same browser/runtime and corpus shape.
Measurement rules
Section titled “Measurement rules”- PERF-07 must compare first-token latency, token-to-token cadence, dropped or stale events, and terminal publication latency. A session-state refactor is justified only if it improves a measured bottleneck without weakening the durable turn or reconnect contract.
- PERF-02 must measure hit rate, retained-entry count, stale-result risk, and rehydration cost. Persisting entries without a vector-generation or index revision would make a fast stale answer possible, so no persistence change is included yet.
- PERF-10 must record provider batch duration, inter-batch wait, total ingest duration, retrieval latency, and retrieval-quality checks. A zero-delay or adaptive policy needs cancellation, rate-limit, and provider-failure tests.
The benchmark is intentionally diagnostic rather than an automatic tuning loop. Results should be attached to the performance PR or issue that proposes the behavior change.