Skip to content

Improve prediction popup latency: domain settings cache + remove tabs.get pre-flight#291

Merged
bartekplus merged 1 commit intomasterfrom
claude/dazzling-hermann
Mar 9, 2026
Merged

Improve prediction popup latency: domain settings cache + remove tabs.get pre-flight#291
bartekplus merged 1 commit intomasterfrom
claude/dazzling-hermann

Conversation

@bartekplus
Copy link
Owner

Summary

  • DomainSettingsCache — caches resolveDomainRuntimeSettings per domain URL with a 500 ms TTL in MessageRouter. Previously, every keystroke prediction triggered 5 parallel chrome.storage reads (≈5–15 ms overhead). Now 50 consecutive predictions for the same domain cost 1 storage read instead of 250. Cache is immediately invalidated on CMD_OPTIONS_PAGE_CONFIG_CHANGE.
  • Remove chrome.tabs.get pre-flightBackgroundServiceWorker.runPrediction was calling chrome.tabs.get(tabId, callback) before every sendMessage just to check if the tab existed, adding ≈5–10 ms of IPC latency. sendMessage already throws if the tab is gone, so the check was redundant. Now sends directly.

Total saving per keystroke: ~15–25 ms of background overhead.

Tests run

  • bun run lint
  • bun run format:check
  • bun run test ✅ — 1304 pass, 0 fail
  • bun run test:e2e (pending CI)
  • bun run check:e2e:coverage (pending CI)

New tests added:

  • tests/DomainSettingsCache.test.ts — 11 unit tests: cache hit/miss, TTL expiry, per-domain isolation, invalidation, and a latency benchmark (cached path ≥5× faster than uncached with 2 ms simulated storage delay).
  • Two regression tests in tests/background.routing.test.ts:
    • Asserts chrome.tabs.get is not called during prediction response dispatch.
    • Asserts the cache is invalidated after CMD_OPTIONS_PAGE_CONFIG_CHANGE so the next prediction sees the updated language.

🤖 Generated with Claude Code

…ing tabs.get pre-flight

Two performance bottlenecks were causing ~15-25 ms of avoidable overhead on
every keystroke prediction:

1. `resolveDomainRuntimeSettings` was called on every prediction request,
   performing 5 parallel chrome.storage reads (~5-15 ms) even though domain
   settings virtually never change between keystrokes.
   Fix: introduce `DomainSettingsCache` (500 ms TTL, per-domain key) in
   `MessageRouter`.  The cache is immediately invalidated when
   `CMD_OPTIONS_PAGE_CONFIG_CHANGE` is received so settings changes still
   take effect without waiting for expiry.

2. `BackgroundServiceWorker.runPrediction` called `chrome.tabs.get` before
   every `sendMessage` as a tab-existence pre-flight, adding ~5-10 ms of
   extra IPC latency.  `sendMessage` already throws when the tab/frame is
   gone, so the pre-flight was redundant.
   Fix: call `chrome.tabs.sendMessage` directly and catch the error.

Performance gain per keystroke: ~15-25 ms less background-side overhead.
50 consecutive predictions for the same domain now incur 1 storage read
instead of 250.

Tests added:
- `tests/DomainSettingsCache.test.ts` — 11 unit tests covering cache hit/miss,
  TTL expiry, per-domain isolation, invalidation, and a latency benchmark
  asserting cached requests are ≥5× faster than uncached ones.
- Two regression tests in `tests/background.routing.test.ts`:
  - Verifies `chrome.tabs.get` is NOT called during prediction dispatch.
  - Verifies the domain settings cache is invalidated after a config change
    so the next prediction sees fresh language/settings values.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@bartekplus bartekplus self-assigned this Mar 9, 2026
@bartekplus bartekplus merged commit 14e5018 into master Mar 9, 2026
8 checks passed
@bartekplus bartekplus deleted the claude/dazzling-hermann branch March 9, 2026 05:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant