Search: typing p95 1.2 s at 10k Logs

kayg commented

2026-10-08 00:34:02 +00:00

Owner

Problem

Bug bash round 2 (#1220, bash-core2) measured Search over 10,000 Logs with 4× CPU throttling (a mid-range laptop): typing-to-visible results p50 843 ms, p95 1,229 ms; first frame p95 535 ms. Server CPU peaked at 450% and RSS at 617 MB during the typing loop. DESIGN §59 budget for a keystroke-to-visible update is far lower.

Expected

Typing in Search shows updated results within the §59 interaction budget at 10k Logs on the perf VM (cold and warm), with cancellation of stale requests (no work for superseded keystrokes, on client and server), and no server CPU spike per keystroke.

Work

Measure first on the perf VM (shared prebuilt release server, flock /root/perf.lock) with the bash-core2 harness, attribute time (client debounce, request, server query, render), fix the top costs, re-measure interleaved against origin/dev. Screenshots at actual size of the palette while typing (390/820/1440, light/dark). Gates: cargo fmt/clippy/test for touched crates, bun run check, bun run test; quote verbatim.

## Problem Bug bash round 2 (#1220, bash-core2) measured Search over 10,000 Logs with 4× CPU throttling (a mid-range laptop): typing-to-visible results p50 843 ms, p95 1,229 ms; first frame p95 535 ms. Server CPU peaked at 450% and RSS at 617 MB during the typing loop. DESIGN §59 budget for a keystroke-to-visible update is far lower. ## Expected Typing in Search shows updated results within the §59 interaction budget at 10k Logs on the perf VM (cold and warm), with cancellation of stale requests (no work for superseded keystrokes, on client and server), and no server CPU spike per keystroke. ## Work Measure first on the perf VM (shared prebuilt release server, flock /root/perf.lock) with the bash-core2 harness, attribute time (client debounce, request, server query, render), fix the top costs, re-measure interleaved against origin/dev. Screenshots at actual size of the palette while typing (390/820/1440, light/dark). Gates: cargo fmt/clippy/test for touched crates, bun run check, bun run test; quote verbatim.

kayg commented

2026-10-08 06:48:50 +00:00

Author

Owner

Starting #1425 on branch job/searchperf-1425, based on origin/dev at d395b6e25da20d8c67b8b9fc1a593b813939c8a7. I am locating the existing Search benchmark and tracing client, server and render costs before making a change.

Starting #1425 on branch `job/searchperf-1425`, based on `origin/dev` at `d395b6e25da20d8c67b8b9fc1a593b813939c8a7`. I am locating the existing Search benchmark and tracing client, server and render costs before making a change.

kayg commented

2026-10-08 06:58:50 +00:00

Author

Owner

Finding: SearchWindow.run() aborts the prior browser request on each query change, but serverSearch() has SERVER_DEBOUNCE_MS = 0 and /api/v1/search runs provider fan-out without a server-side supersession signal. Thus the browser stops waiting, while an already accepted older request can keep using server CPU. I am measuring this with a 10,000-Log corpus before changing the request path.

Finding: `SearchWindow.run()` aborts the prior browser request on each query change, but `serverSearch()` has `SERVER_DEBOUNCE_MS = 0` and `/api/v1/search` runs provider fan-out without a server-side supersession signal. Thus the browser stops waiting, while an already accepted older request can keep using server CPU. I am measuring this with a 10,000-Log corpus before changing the request path.

kayg referenced this issue from a commit

2026-10-08 08:00:15 +00:00

Add Search typing performance profile for #1425

kayg commented

2026-10-08 08:10:56 +00:00

Author

Owner

The profile has not reached Search measurement yet. The prebuilt baseline server exits during startup with Error: NotFound in the root.open_prepare_recover phase, after it logs the expected temporary Instance and User data directories. I am tracing its filesystem calls under the required Perf VM lock to identify the failing operation. No benchmark numbers have been recorded yet.

The profile has not reached Search measurement yet. The prebuilt baseline server exits during startup with `Error: NotFound` in the `root.open_prepare_recover` phase, after it logs the expected temporary Instance and User data directories. I am tracing its filesystem calls under the required Perf VM lock to identify the failing operation. No benchmark numbers have been recorded yet.

kayg commented

2026-10-08 08:22:15 +00:00

Author

Owner

The first cargo test -p calternal-server run completed 278 unit tests successfully, then failed the deterministic performance guard. perf-lint identified the existing exact cache.raw-read pin for apps/web/src/lib/search/server.ts as unused or changed because the serverSearch::ask syntax changed. I am refreshing only that live fingerprint while keeping its owner, reason, limit, and the ratchet count unchanged, then I will rerun the crate gate.

The first `cargo test -p calternal-server` run completed 278 unit tests successfully, then failed the deterministic performance guard. `perf-lint` identified the existing exact `cache.raw-read` pin for `apps/web/src/lib/search/server.ts` as unused or changed because the `serverSearch::ask` syntax changed. I am refreshing only that live fingerprint while keeping its owner, reason, limit, and the ratchet count unchanged, then I will rerun the crate gate.

kayg commented

2026-10-08 08:32:03 +00:00

Author

Owner

The Perf VM trace narrows the baseline startup failure: root.open_prepare_recover finishes in 198.6 ms, and the missing .system/journal entry is handled by Root::recover. The server then exits with NotFound before listening because the prebuilt origin/dev binary has no embedded _app/version.json; retain_frontend_assets requires that manifest. I will compare the origin/dev web build with the branch web build on one web-enabled debug server. The old client sends no Search generation headers, so its per-prefix requests still exercise the pre-fix path; the after run also checks server cancellation. This keeps the client A/B comparable without compiling a release binary on this job.

The Perf VM trace narrows the baseline startup failure: `root.open_prepare_recover` finishes in 198.6 ms, and the missing `.system/journal` entry is handled by `Root::recover`. The server then exits with `NotFound` before listening because the prebuilt `origin/dev` binary has no embedded `_app/version.json`; `retain_frontend_assets` requires that manifest. I will compare the origin/dev web build with the branch web build on one web-enabled debug server. The old client sends no Search generation headers, so its per-prefix requests still exercise the pre-fix path; the after run also checks server cancellation. This keeps the client A/B comparable without compiling a release binary on this job.

kayg commented

2026-10-08 08:33:28 +00:00

Author

Owner

The second full cargo test -p calternal-server run completed 278 active unit tests, then failed the deterministic performance guard on the existing exact bounds.byte_cap pin for crates/calternal-server/src/main.rs (search:byte_cap). Extracting the Search handler changed that syntax fingerprint. I am refreshing this one pin and its #1058 checkpoint without changing the exception limit or contracts/perf/ratchet.json.

The second full `cargo test -p calternal-server` run completed 278 active unit tests, then failed the deterministic performance guard on the existing exact `bounds.byte_cap` pin for `crates/calternal-server/src/main.rs` (`search:byte_cap`). Extracting the Search handler changed that syntax fingerprint. I am refreshing this one pin and its #1058 checkpoint without changing the exception limit or `contracts/perf/ratchet.json`.

kayg commented

2026-10-08 08:43:51 +00:00

Author

Owner

The deterministic scripts/perf-lint --check guard now passes the refreshed cache and Search response-bound pins, then reports the prior io.unresolved-call entry search:search:0ce2f8cb185f4047 as unused. The extraction moved that same home.as_str call into search_request, and the live parser reports its current identity as search:search_request:0ce2f8cb185f4047 with helper hash 907bf85ffeae8bc5f16487d76b77a263b0fc394730f0cc7ea3b9ee0e14de2983. I am updating exact identities and checking for any genuinely new findings before continuing.

The deterministic `scripts/perf-lint --check` guard now passes the refreshed cache and Search response-bound pins, then reports the prior `io.unresolved-call` entry `search:search:0ce2f8cb185f4047` as unused. The extraction moved that same `home.as_str` call into `search_request`, and the live parser reports its current identity as `search:search_request:0ce2f8cb185f4047` with helper hash `907bf85ffeae8bc5f16487d76b77a263b0fc394730f0cc7ea3b9ee0e14de2983`. I am updating exact identities and checking for any genuinely new findings before continuing.

kayg commented

2026-10-08 09:18:30 +00:00

Author

Owner

Perf profile startup diagnosis: the trace shows RustEmbed can stat the embedded version.json at the compile-time worktree path, but the debug server then sees no frontend asset because that path is a symlink to a different canonical directory on the Perf VM. I will stage the matching production build as a real directory at the compile-time path and rerun the profile. This is a benchmark setup issue; no product change is needed.

kayg commented

2026-10-08 09:34:50 +00:00

Author

Owner

Perf VM baseline run reached the real Search flow at load average 1.78, 1.22, 1.05. The uploaded Daily note was indexed, but the cold profile timed out waiting for a visible Search option containing “needle”; the bench correctly rejected the run and saved no report. I am checking the response and UI selector before another locked run.

kayg commented

2026-10-08 09:46:48 +00:00

Author

Owner

The baseline timeout came from the profile fixture: needle appeared in all 10,000 Log bodies, so the cold query measured a 10,000-hit result set. The issue’s corpus is 10,000 Logs, not 10,000 matches. I changed the fixture so needle appears in one real Log, added a standard Daily note heading, and require the last block to be indexed as kind=log before profiling.

The baseline timeout came from the profile fixture: `needle` appeared in all 10,000 Log bodies, so the cold query measured a 10,000-hit result set. The issue’s corpus is 10,000 Logs, not 10,000 matches. I changed the fixture so `needle` appears in one real Log, added a standard Daily note heading, and require the last block to be indexed as `kind=log` before profiling.

kayg commented

2026-10-08 10:17:57 +00:00

Author

Owner

The exact-response diagnostic shows the UI selector was not the primary issue: GET /api/v1/search?q=needle&semantic=false returned HTTP 200 with zero hits, and the UI list was correctly hidden. The fixture’s last real Log is indexed and found as a kind=log hit by tokenitem09999. I will use that proven unique token for the typing and cancellation profiles and assert a visible Log row.

The exact-response diagnostic shows the UI selector was not the primary issue: `GET /api/v1/search?q=needle&semantic=false` returned HTTP 200 with zero hits, and the UI list was correctly hidden. The fixture’s last real Log is indexed and found as a `kind=log` hit by `tokenitem09999`. I will use that proven unique token for the typing and cancellation profiles and assert a visible Log row.

kayg commented

2026-10-08 10:24:58 +00:00

Author

Owner

The browser probe observed the exact final Log on one /api/v1/search?q=tokenitem09999&limit=20&semantic=false request, then an immediate identical request returned 0 hits. The earlier preflight stopped after the first hit and therefore masked this unstable fixture state. I am changing setup to require consecutive successful reads and checking again after Files navigation before recording any performance sample.

The browser probe observed the exact final Log on one `/api/v1/search?q=tokenitem09999&limit=20&semantic=false` request, then an immediate identical request returned 0 hits. The earlier preflight stopped after the first hit and therefore masked this unstable fixture state. I am changing setup to require consecutive successful reads and checking again after Files navigation before recording any performance sample.

kayg commented

2026-10-08 10:31:48 +00:00

Author

Owner

The repeated fixture probe reports timed_out=false, zero hits, and indexing=true after 60 seconds while the 10,000-Log file is being added. This is an Index readiness wait, not a Search route timeout. The profile now waits for the API to report indexing=false and then requires the final Log in three sequential requests before measuring.

The repeated fixture probe reports `timed_out=false`, zero hits, and `indexing=true` after 60 seconds while the 10,000-Log file is being added. This is an Index readiness wait, not a Search route timeout. The profile now waits for the API to report `indexing=false` and then requires the final Log in three sequential requests before measuring.

kayg commented

2026-10-08 10:37:33 +00:00

Author

Owner

The first readiness-correct after profile completed on the Perf VM with 10,000 real Logs and 4× CPU throttling (load average 1.39 at start). Warm input-to-visible first-frame p50/p95 was 65.3/163.4 ms; cold was 101.8/154.3 ms. The current §59 p95 budget is 150 ms, so this run misses it by 13.4 ms warm. Server route p50/p95 was 40.852/89.909 ms; peak process CPU was 189.72% and peak RSS 788,160,512 bytes. The old issue measurement was 1,229 ms input-to-visible p95 and 450% peak CPU. I am running the interleaved origin/dev comparison before deciding if another fix is needed; this run failed only the new 150 ms profile assertion, after writing the metrics JSON.

kayg commented

2026-10-08 10:46:03 +00:00

Author

Owner

The readiness-correct release-server profile showed the current 14-character tokenitem09999 query returns one Log. It does not reproduce the issue's 10,000 matching-Log typing workload. I will use the fixture's shared Searchperf term for cold/warm typing and screenshots, while keeping the unique final Log query as an Index-readiness assertion. The earlier unique-query A/B values are diagnostic only; I am rerunning the pair on the matching workload.

The readiness-correct release-server profile showed the current 14-character `tokenitem09999` query returns one Log. It does not reproduce the issue's 10,000 matching-Log typing workload. I will use the fixture's shared `Searchperf` term for cold/warm typing and screenshots, while keeping the unique final Log query as an Index-readiness assertion. The earlier unique-query A/B values are diagnostic only; I am rerunning the pair on the matching workload.

kayg referenced this issue from a commit

2026-10-08 10:49:45 +00:00

Wait for Search Index in perf profile #1425

kayg referenced this issue from a commit

2026-10-08 10:49:45 +00:00

Profile all 10k matching Logs for #1425

kayg commented

2026-10-08 10:55:35 +00:00

Author

Owner

The full-corpus release A/B (same origin/dev release server, 10,000 matching Logs, 4× renderer throttle; load 3.64/3.55/2.54 at after start) shows the current 60 ms client debounce reduces warm request count from 11 to 3 and server peak CPU from 279.36% to 124.70%. Warm input-to-visible first-frame p95 moves from 187.2 ms to 216.3 ms, above the §59 150 ms budget; cold p95 is 281.3 ms. This shared release server predates the new server cancellation route, so the run isolates the client behavior. I am removing the fixed wait and will measure the client abort plus branch-server cancellation path.

The full-corpus release A/B (same `origin/dev` release server, 10,000 matching Logs, 4× renderer throttle; load 3.64/3.55/2.54 at after start) shows the current 60 ms client debounce reduces warm request count from 11 to 3 and server peak CPU from 279.36% to 124.70%. Warm input-to-visible first-frame p95 moves from 187.2 ms to 216.3 ms, above the §59 150 ms budget; cold p95 is 281.3 ms. This shared release server predates the new server cancellation route, so the run isolates the client behavior. I am removing the fixed wait and will measure the client abort plus branch-server cancellation path.

kayg commented

2026-10-08 11:26:00 +00:00

Author

Owner

Perf run after-b8 was incomplete: the fixture readiness checks passed for the 10,000-Log Daily note, but the warm typing phase timed out while waiting for a visible Log row after entering the shared Searchperf query. It wrote no profile JSON, so I am not counting it as a latency result. I added bounded diagnostics that distinguish an empty server response from a palette rendering issue. The next full-corpus run will use those diagnostics.

kayg commented

2026-10-08 11:52:00 +00:00

Author

Owner

The full-corpus profile seeded and indexed all 10,000 Logs, then completed cold and warm typing. The run stopped in checkServerCancellation: its page.evaluate callback referenced Node's LAST_LOG_QUERY without serializing it into the browser context (ReferenceError: LAST_LOG_QUERY is not defined). No profile or screenshot set was saved. I have fixed the probe to pass the query as an argument and am rerunning the complete scenario.

The full-corpus profile seeded and indexed all 10,000 Logs, then completed cold and warm typing. The run stopped in `checkServerCancellation`: its `page.evaluate` callback referenced Node's `LAST_LOG_QUERY` without serializing it into the browser context (`ReferenceError: LAST_LOG_QUERY is not defined`). No profile or screenshot set was saved. I have fixed the probe to pass the query as an argument and am rerunning the complete scenario.

kayg commented

2026-10-08 11:59:41 +00:00

Author

Owner

The corrected browser probe passed Index readiness and the server cancellation check, then failed during warm typing. Its bounded diagnostics show the Search API returned HTTP 200 with 20 log results whose titles matched the 10-character query, while #search-results remained hidden and no Log row appeared within 30 seconds. The run saved no profile or screenshots. I am tracing the client result-visibility state before recording a candidate measurement.

The corrected browser probe passed Index readiness and the server cancellation check, then failed during warm typing. Its bounded diagnostics show the Search API returned HTTP 200 with 20 `log` results whose titles matched the 10-character query, while `#search-results` remained hidden and no Log row appeared within 30 seconds. The run saved no profile or screenshots. I am tracing the client result-visibility state before recording a candidate measurement.

kayg commented

2026-10-08 12:08:25 +00:00

Author

Owner

A diagnostic rerun completed all 10 warm typing rounds and kept the Log rows visible; the earlier hidden-list symptom did not recur. It failed at the final stale-request assertion because Playwright 1.63 returns request.failure() as a record, while the probe called .includes() on it as if it were a string. That event callback threw, so aborted requests were reported as zero. The diagnostic run measured a warm first-visible p95 of 240.2 ms and server-route p95 of 172.067 ms on the debug server with response decoding enabled; I will not use those diagnostic numbers as the final release comparison. The probe now reads errorText, and the release run will check the budget without diagnostic instrumentation.

A diagnostic rerun completed all 10 warm typing rounds and kept the Log rows visible; the earlier hidden-list symptom did not recur. It failed at the final stale-request assertion because Playwright 1.63 returns `request.failure()` as a record, while the probe called `.includes()` on it as if it were a string. That event callback threw, so aborted requests were reported as zero. The diagnostic run measured a warm first-visible p95 of 240.2 ms and server-route p95 of 172.067 ms on the debug server with response decoding enabled; I will not use those diagnostic numbers as the final release comparison. The probe now reads `errorText`, and the release run will check the budget without diagnostic instrumentation.

kayg commented

2026-10-08 12:39:52 +00:00

Author

Owner

The release-server browser run indexed the 10,000-Log fixture and captured the 390 px light Files view and click-open Search state. It then typed the measured query but did not show a Log row within 15 seconds on the phone. The run exited before writing its profile or completing the screenshot set, so it is not counted as a performance measurement. I am adding bounded phone-path diagnostics and rerunning it.

kayg commented

2026-10-08 13:05:25 +00:00

Author

Owner

Release profile run release7 reproduced the 390 px phone click path after the 10,000-Log fixture was indexed. Search opened, but at the end of the 15 s wait the combobox value length was 0 and document.activeElement was #chrome-sidebar-toggle; the visible Search list had seven navigation rows. A direct Search API request returned 200 with 20 Log hits. The harness had typed into the still-focused sidebar toggle, so this was a real focus handoff defect rather than a missing Index result.

The phone sidebar's Bits UI close-autofocus ran after its spring and restored the toggle over the Search field. I changed that close handoff to preserve focus while Search is open. The browser profile now waits for the sidebar sheet to detach and asserts the Search field owns focus, with no focus-visible ring, before typing. I am rerunning the release-server profile with the updated production web build.

Release profile run `release7` reproduced the 390 px phone click path after the 10,000-Log fixture was indexed. Search opened, but at the end of the 15 s wait the combobox value length was 0 and `document.activeElement` was `#chrome-sidebar-toggle`; the visible Search list had seven navigation rows. A direct Search API request returned 200 with 20 Log hits. The harness had typed into the still-focused sidebar toggle, so this was a real focus handoff defect rather than a missing Index result. The phone sidebar's Bits UI close-autofocus ran after its spring and restored the toggle over the Search field. I changed that close handoff to preserve focus while Search is open. The browser profile now waits for the sidebar sheet to detach and asserts the Search field owns focus, with no focus-visible ring, before typing. I am rerunning the release-server profile with the updated production web build.

kayg commented

2026-10-08 14:13:48 +00:00

Author

Owner

Release 9 completed the 10,000-Log profile but stopped during the screenshot guard. The browser bundle ID was a96d2f51013321bf1a70955b0d33213c1ef6bc9f; the server reports 626584190ae6ec7949db5850a9db1dfdef89c905, so the app showed “Update available”. I am rebuilding the production bundle with the server's build ID, then I will repeat the locked profile and captures.

After merging origin/dev, cargo test -p calternal-server reported 277 passed, 1 failed, 12 ignored. The failure was wire::tests::live_apps_run_in_separate_processes: its startup_serves_http_while_content_type_backfill_runs subprocess timed out waiting for the backfill phase on /healthz after 122.73 seconds. No test expectation was changed.

Release 9 completed the 10,000-Log profile but stopped during the screenshot guard. The browser bundle ID was `a96d2f51013321bf1a70955b0d33213c1ef6bc9f`; the server reports `626584190ae6ec7949db5850a9db1dfdef89c905`, so the app showed “Update available”. I am rebuilding the production bundle with the server's build ID, then I will repeat the locked profile and captures. After merging `origin/dev`, `cargo test -p calternal-server` reported 277 passed, 1 failed, 12 ignored. The failure was `wire::tests::live_apps_run_in_separate_processes`: its `startup_serves_http_while_content_type_backfill_runs` subprocess timed out waiting for the backfill phase on `/healthz` after 122.73 seconds. No test expectation was changed.

kayg commented

2026-10-08 14:36:00 +00:00

Author

Owner

Release 10 used a matching web/server build ID. Its click-open checks passed, then its keyboard-shortcut check found :focus-visible on the Search field. The Search dialog used raw .focus() after the shortcut had set keyboard modality. I changed that mount focus to the shared focusQuietly helper with an explicit suppress-ring behavior, added tests for suppressed shortcut focus and modality-aware restores, and will repeat the production screenshots.

Release 10 used a matching web/server build ID. Its click-open checks passed, then its keyboard-shortcut check found `:focus-visible` on the Search field. The Search dialog used raw `.focus()` after the shortcut had set keyboard modality. I changed that mount focus to the shared `focusQuietly` helper with an explicit suppress-ring behavior, added tests for suppressed shortcut focus and modality-aware restores, and will repeat the production screenshots.

kayg commented

2026-10-08 14:46:31 +00:00

Author

Owner

The matching-build diagnostic run collected 164 ms p95 from input to the Search request, 36 ms p95 for the server route, and 212 ms p95 to the first visible result. The run is incomplete because its shortcut focus check found the ring fixed in the latest commit, so I am treating these as diagnostics rather than a budget pass. The provider registry started all local synchronous matchers before it called the server provider. I have changed content-mode dispatch to start the Search request first while preserving immediate local results, and added a regression assertion for that order.

kayg commented

2026-10-08 14:51:44 +00:00

Author

Owner

The final performance contract check found a second stale exact pin after the focus change: render.bound for the Search dialog's flat.slice(range.start, range.end) list. Its surface hash includes the Svelte file fingerprint, so the same source edit also changes fingerprints for the six Search dialog lists. I am refreshing those exact registry and exception hashes; the rule limits, exception counts and ratchet ceilings stay unchanged.

The final performance contract check found a second stale exact pin after the focus change: `render.bound` for the Search dialog's `flat.slice(range.start, range.end)` list. Its surface hash includes the Svelte file fingerprint, so the same source edit also changes fingerprints for the six Search dialog lists. I am refreshing those exact registry and exception hashes; the rule limits, exception counts and ratchet ceilings stay unchanged.

kayg referenced this issue from a commit

2026-10-08 15:02:46 +00:00

Start Search requests before local matching

kayg referenced this issue from a commit

2026-10-08 15:02:46 +00:00

Refresh Search performance fingerprints

kayg commented

2026-10-08 15:20:37 +00:00

Author

Owner

The production Web build is synced to the perf VM and matches the prebuilt Search server build ID. The final 10k-Log profile is queued through perf-run because the single-tenant VM is in use by another benchmark. No final measurement has started outside the lock; the queued run will record load and capture the full screenshot matrix under the lock.

The production Web build is synced to the perf VM and matches the prebuilt Search server build ID. The final 10k-Log profile is queued through `perf-run` because the single-tenant VM is in use by another benchmark. No final measurement has started outside the lock; the queued run will record load and capture the full screenshot matrix under the lock.

kayg commented

2026-10-08 15:22:39 +00:00

Author

Owner

Job report — #1425 remains open

Head: 0fa596ff27d6bb937cf759094f5bc724d9f9719a.

Built

Search requests now start before local synchronous matching. Local results still stream in the same task.
Search cancels superseded work in the browser and in the server. The server keys generations by User and Search window, caps tracking at 256 windows, and expires idle entries after 30 seconds.
Search returns keyword hits before hybrid retrieval. Repeated Log date labels use a 256-entry locale-aware cache.
Search keeps focus after the phone sidebar closes. Programmatic focus after Cmd+K suppresses the focus ring; the shared helper still preserves modality-aware restore behavior.
Added/extended the 10,000-Log Search profile and real-browser assertions for cancellation, loaded results, focus rings, and the 390/820/1440 light/dark screenshot matrix.

Performance evidence and remaining work

The origin/dev baseline (d395b6e25da20d8c67b8b9fc1a593b813939c8a7, perf VM, 10,000 Logs, 4× CPU) measured warm first-visible p50/p95 of 76.3/187.2 ms and cold p50/p95 of 126.7/238.5 ms. Its warm input-to-request p95 was 374.6 ms; server-route p95 was 200.87 ms; peak server CPU was 279.36% and peak RSS was 713,293,824 bytes.

The last complete typing measurement was diagnostic only: release10 measured warm first-visible p50/p95 of 109.2/212 ms, input-to-request p95 of 164.4 ms, and server-route p95 of 36.151 ms. It failed the shortcut focus-ring assertion, so it is not a budget pass. Release9 also stopped on a build-ID mismatch toast; release8 stopped on phone sidebar focus handoff. These incomplete runs are not budget samples.

The final profile after the server-first dispatch change did not start. The single-tenant perf VM was held by another benchmark with an estimated 55-minute run. I queued the run through perf-run, then canceled it before it acquired the lock because this job had passed the shared four-hour limit. No final 10,000-Log measurement or post-fix screenshot matrix exists. I did not update docs/perf/baseline.json or attach failed screenshots. The next run must rebuild/sync the Web bundle, run bench/search-typing-1425.sh after release11 through perf-run, record load, verify the 150 ms cold/warm budget, update the baseline, and attach all 30 screenshots.

Expected cost: Search reads one bounded indexed result page for each active typed prefix. This profile covers a 10-character query over 10,000 indexed Logs, ten warm rounds at 45 ms per keystroke, plus a cold query, with 4× CPU throttling.

Verification

cargo fmt --check: exited 0 with no output.
cargo clippy -p calternal-server --all-targets -- -D warnings: Finished \dev` profile [unoptimized + debuginfo] target(s) in 1m 30s`.
cargo test -p calternal-server did not pass. Under shared-host load, wire::tests::startup_serves_http_while_content_type_backfill_runs timed out waiting for the phase on /healthz:
content-type backfill phase did not appear on /healthz: Elapsed(())
test result: FAILED. 277 passed; 1 failed; 12 ignored; 0 measured; 0 filtered out; finished in 281.51s
bun run check: perf-lint: PASS; 0 violations; 22544 scoped exceptions; svelte-check found 0 errors and 4 warnings in 2 files.
bun run test -- --maxWorkers=2:
Test Files 297 passed (297)
Tests 2123 passed (2123)
Duration 392.79s (environment 30%, import 24%, transform 23%, tests 16%, setup 6%)
Focused Search/focus Vitest run: 3 files passed, 26 tests passed.
cargo clean: Removed 25634 files, 15.7GiB total.

Decisions (DESIGN was silent)

Start the content-mode server provider first to overlap network/index work with local matching while preserving immediate local results.
Keep generation headers optional. Invalid metadata disables supersession. When the 256-window registry is full, leave the new request untracked instead of evicting another User's work.
Keep the 80 ms delay before the hybrid request and cap the Log date-label cache at 256 entries.
Use the prebuilt Search server at source 626584190ae6ec7949db5850a9db1dfdef89c905; set the production Web build ID to that server ID for the test environment. The Web source revision is recorded separately.

Known gaps

The final perf measurement, 150 ms budget result, screenshot attachments, and docs/perf/baseline.json update remain outstanding.
The server test has the timed startup failure above. The web check reports four existing Mail/Money CSS warnings.
The full e2e and adversarial merge-round matrices remain to be run.

Issue remains open.

## Job report — #1425 remains open Head: `0fa596ff27d6bb937cf759094f5bc724d9f9719a`. ### Built - Search requests now start before local synchronous matching. Local results still stream in the same task. - Search cancels superseded work in the browser and in the server. The server keys generations by User and Search window, caps tracking at 256 windows, and expires idle entries after 30 seconds. - Search returns keyword hits before hybrid retrieval. Repeated Log date labels use a 256-entry locale-aware cache. - Search keeps focus after the phone sidebar closes. Programmatic focus after Cmd+K suppresses the focus ring; the shared helper still preserves modality-aware restore behavior. - Added/extended the 10,000-Log Search profile and real-browser assertions for cancellation, loaded results, focus rings, and the 390/820/1440 light/dark screenshot matrix. ### Performance evidence and remaining work The origin/dev baseline (`d395b6e25da20d8c67b8b9fc1a593b813939c8a7`, perf VM, 10,000 Logs, 4× CPU) measured warm first-visible p50/p95 of 76.3/187.2 ms and cold p50/p95 of 126.7/238.5 ms. Its warm input-to-request p95 was 374.6 ms; server-route p95 was 200.87 ms; peak server CPU was 279.36% and peak RSS was 713,293,824 bytes. The last complete typing measurement was diagnostic only: release10 measured warm first-visible p50/p95 of 109.2/212 ms, input-to-request p95 of 164.4 ms, and server-route p95 of 36.151 ms. It failed the shortcut focus-ring assertion, so it is not a budget pass. Release9 also stopped on a build-ID mismatch toast; release8 stopped on phone sidebar focus handoff. These incomplete runs are not budget samples. The final profile after the server-first dispatch change did not start. The single-tenant perf VM was held by another benchmark with an estimated 55-minute run. I queued the run through `perf-run`, then canceled it before it acquired the lock because this job had passed the shared four-hour limit. No final 10,000-Log measurement or post-fix screenshot matrix exists. I did not update `docs/perf/baseline.json` or attach failed screenshots. The next run must rebuild/sync the Web bundle, run `bench/search-typing-1425.sh after release11` through `perf-run`, record load, verify the 150 ms cold/warm budget, update the baseline, and attach all 30 screenshots. Expected cost: Search reads one bounded indexed result page for each active typed prefix. This profile covers a 10-character query over 10,000 indexed Logs, ten warm rounds at 45 ms per keystroke, plus a cold query, with 4× CPU throttling. ### Verification - `cargo fmt --check`: exited 0 with no output. - `cargo clippy -p calternal-server --all-targets -- -D warnings`: `Finished \`dev\` profile [unoptimized + debuginfo] target(s) in 1m 30s`. - `cargo test -p calternal-server` did not pass. Under shared-host load, `wire::tests::startup_serves_http_while_content_type_backfill_runs` timed out waiting for the phase on `/healthz`: `content-type backfill phase did not appear on /healthz: Elapsed(())` `test result: FAILED. 277 passed; 1 failed; 12 ignored; 0 measured; 0 filtered out; finished in 281.51s` - `bun run check`: `perf-lint: PASS; 0 violations; 22544 scoped exceptions`; `svelte-check found 0 errors and 4 warnings in 2 files`. - `bun run test -- --maxWorkers=2`: `Test Files 297 passed (297)` `Tests 2123 passed (2123)` `Duration 392.79s (environment 30%, import 24%, transform 23%, tests 16%, setup 6%)` - Focused Search/focus Vitest run: 3 files passed, 26 tests passed. - `cargo clean`: `Removed 25634 files, 15.7GiB total`. ### Decisions (DESIGN was silent) - Start the content-mode server provider first to overlap network/index work with local matching while preserving immediate local results. - Keep generation headers optional. Invalid metadata disables supersession. When the 256-window registry is full, leave the new request untracked instead of evicting another User's work. - Keep the 80 ms delay before the hybrid request and cap the Log date-label cache at 256 entries. - Use the prebuilt Search server at source `626584190ae6ec7949db5850a9db1dfdef89c905`; set the production Web build ID to that server ID for the test environment. The Web source revision is recorded separately. ### Known gaps - The final perf measurement, 150 ms budget result, screenshot attachments, and `docs/perf/baseline.json` update remain outstanding. - The server test has the timed startup failure above. The web check reports four existing Mail/Money CSS warnings. - The full e2e and adversarial merge-round matrices remain to be run. Issue remains open.

kayg commented

2026-10-08 18:04:38 +00:00

Author

Owner

Started searchperf2 on job/searchperf-1425 at 0fa596ff27; base origin/dev is af202e1514. I am building the production Web app and preparing the interleaved perf VM and Mac Chrome measurements plus the 12-shot UI evidence.

Started searchperf2 on job/searchperf-1425 at 0fa596ff27d6bb937cf759094f5bc724d9f9719a; base origin/dev is af202e1514955ddf0f8b4b3d2503c780d807ed84. I am building the production Web app and preparing the interleaved perf VM and Mac Chrome measurements plus the 12-shot UI evidence.

kayg commented

2026-10-08 18:29:39 +00:00

Author

Owner

Mac setup note for #1425: macOS 27 arm64 has Chrome 154 under the User Applications folder. I failed to confirm this job had acquired /tmp/mac-bench.lock before starting a temporary headless Chrome profile on port 19223; another job held the lock. I stopped all of my SSH sessions immediately. I did not run the Search profile or capture screenshots. I did query the temporary browser's GPU renderer. A temporary Chrome process and profile may remain under ~/calternal-bench/searchperf2/chrome-profile-19223; I will stop and remove them only after this job reacquires the lock.

Mac setup note for #1425: macOS 27 arm64 has Chrome 154 under the User Applications folder. I failed to confirm this job had acquired `/tmp/mac-bench.lock` before starting a temporary headless Chrome profile on port 19223; another job held the lock. I stopped all of my SSH sessions immediately. I did not run the Search profile or capture screenshots. I did query the temporary browser's GPU renderer. A temporary Chrome process and profile may remain under `~/calternal-bench/searchperf2/chrome-profile-19223`; I will stop and remove them only after this job reacquires the lock.

kayg commented

2026-10-08 18:32:11 +00:00

Author

Owner

Progress: production Web assets are built for head 0fa596ff27d6bb937cf759094f5bc724d9f9719a and the origin/dev comparison af202e1514955ddf0f8b4b3d2503c780d807ed84. The Perf VM lock is still held by another job, so no Perf VM samples have run. The Mac lock is also currently held by another job; my lock acquisition is waiting and no Mac Search samples or screenshots have run. The six-run alternating Perf VM sequence is staged and will record load averages inside the lock.

Progress: production Web assets are built for head `0fa596ff27d6bb937cf759094f5bc724d9f9719a` and the origin/dev comparison `af202e1514955ddf0f8b4b3d2503c780d807ed84`. The Perf VM lock is still held by another job, so no Perf VM samples have run. The Mac lock is also currently held by another job; my lock acquisition is waiting and no Mac Search samples or screenshots have run. The six-run alternating Perf VM sequence is staged and will record load averages inside the lock.

kayg commented

2026-10-08 18:36:56 +00:00

Author

Owner

Measurement finding: HEAD changes crates/calternal-server/src/main.rs and adds search_cancellation.rs relative to origin/dev, and the Search profile checks that cancellation contract. Using the shared origin/dev server for both builds would leave the head run on the old cancellation behavior. I will use the shared release binary for origin/dev and build only calternal-server in release mode for head; this avoids a workspace build and lets both runs exercise their matching server.

Measurement finding: `HEAD` changes `crates/calternal-server/src/main.rs` and adds `search_cancellation.rs` relative to origin/dev, and the Search profile checks that cancellation contract. Using the shared origin/dev server for both builds would leave the head run on the old cancellation behavior. I will use the shared release binary for origin/dev and build only `calternal-server` in release mode for head; this avoids a workspace build and lets both runs exercise their matching server.

kayg commented

2026-10-08 19:14:00 +00:00

Author

Owner

The paired profile is staged on the Perf VM, but its lock is now held by an active 60-minute measurement lease. I am keeping the six-run profile queued until the lock releases. The branch-matched server release build is underway locally.

kayg commented

2026-10-08 19:24:17 +00:00

Author

Owner

Measurement baseline is pinned to this branch's origin/dev base, af202e1514955ddf0f8b4b3d2503c780d807ed84. The profile harness labels baseline as the old client and asserts it sends no Search generation headers. The freshly fetched origin/dev (cc1af3c12b68ad26c8403adde1be39c096b9ddea) has since rewritten Search and removed this profile file, so using it would mix later Search changes into the #1425 comparison and invalidate those baseline assertions. I will still merge the fetched origin/dev before final verification.

Measurement baseline is pinned to this branch's origin/dev base, `af202e1514955ddf0f8b4b3d2503c780d807ed84`. The profile harness labels baseline as the old client and asserts it sends no Search generation headers. The freshly fetched `origin/dev` (`cc1af3c12b68ad26c8403adde1be39c096b9ddea`) has since rewritten Search and removed this profile file, so using it would mix later Search changes into the #1425 comparison and invalidate those baseline assertions. I will still merge the fetched `origin/dev` before final verification.

kayg commented

2026-10-08 19:43:04 +00:00

Author

Owner

The first Perf lease produced no samples: all three baseline attempts exited 2 because the shared origin server had the staged filename calternal-server-release while the runner expected calternal-server-origin-release; all three head attempts stopped before writing a profile with ETXTBSY because the head executable became visible during tar extraction. I confirmed the exact errors in the runner logs. I am renaming the complete origin binary and will rerun after ensuring the head executable is fully present before starting the locked run.

The first Perf lease produced no samples: all three baseline attempts exited 2 because the shared origin server had the staged filename `calternal-server-release` while the runner expected `calternal-server-origin-release`; all three head attempts stopped before writing a profile with `ETXTBSY` because the head executable became visible during tar extraction. I confirmed the exact errors in the runner logs. I am renaming the complete origin binary and will rerun after ensuring the head executable is fully present before starting the locked run.

kayg commented

2026-10-08 19:51:41 +00:00

Author

Owner

The second locked run also produced no metrics. Head server startup failed in all three rounds because the copied release binary could not find libsherpa-onnx-c-api.so; that library is available in the shared server target tree. Origin/dev started, but its browser page crashed in all three rounds while waiting for the real uploaded Log file row (.fc-item), before writing any profile JSON. Load5 at the start was 3.31. I will set the child server's library path and make one corrected full run; I will not use the failed attempts as performance data.

The second locked run also produced no metrics. Head server startup failed in all three rounds because the copied release binary could not find `libsherpa-onnx-c-api.so`; that library is available in the shared server target tree. Origin/dev started, but its browser page crashed in all three rounds while waiting for the real uploaded Log file row (`.fc-item`), before writing any profile JSON. Load5 at the start was 3.31. I will set the child server's library path and make one corrected full run; I will not use the failed attempts as performance data.

kayg commented

2026-10-08 20:21:13 +00:00

Author

Owner

The third locked run wrote no profile JSON. The server library path is fixed: baseline processes reached the UI but the page crashed three times while waiting for the uploaded Log row; the branch server started successfully with the shared Sherpa/ONNX libraries, but Playwright 1.63 reported Invalid InterceptionId and then the same page crash. I will check the already-installed browser runtime and use one corrected harness run if its Playwright package/browser versions are compatible. The fixed decision rule still applies; failed runs are not measurements.

The third locked run wrote no profile JSON. The server library path is fixed: baseline processes reached the UI but the page crashed three times while waiting for the uploaded Log row; the branch server started successfully with the shared Sherpa/ONNX libraries, but Playwright 1.63 reported `Invalid InterceptionId` and then the same page crash. I will check the already-installed browser runtime and use one corrected harness run if its Playwright package/browser versions are compatible. The fixed decision rule still applies; failed runs are not measurements.

kayg commented

2026-10-08 20:25:35 +00:00

Author

Owner

The Playwright 1.64 retry also produced no samples because its launcher expects chromium_headless_shell-1248/chrome-headless-shell-linux64/chrome-headless-shell; I had copied the full Chromium directory only. This is a browser-path setup failure before profiling, not performance data. The matching headless-shell directory is available locally. A new Perf job holds the VM now; I am queueing one final run for after that lease.

The Playwright 1.64 retry also produced no samples because its launcher expects `chromium_headless_shell-1248/chrome-headless-shell-linux64/chrome-headless-shell`; I had copied the full Chromium directory only. This is a browser-path setup failure before profiling, not performance data. The matching headless-shell directory is available locally. A new Perf job holds the VM now; I am queueing one final run for after that lease.

kayg commented

2026-10-08 20:51:40 +00:00

Author

Owner

Perf VM comparison completed under the perf-run lock. It alternated three origin/dev baseline rounds from branch base af202e1514 with three head rounds at 0fa596ff27. The recorded load5 values at each run start were 1.84, 2.54, 3.07, 3.30, 3.59 and 3.71.

Median warm first-visible p50/p95: baseline 99.3/216.4 ms; head 95.5/200.8 ms. Median cold first-visible p50/p95: baseline 96.4/273.2 ms; head 180.3/350.5 ms. All six profiles were saved. The three head benchmark commands exited 1 because the Perf VM profiles exceed the benchmark's 150 ms cold/warm p95 assertions; the user-set decision still depends on Mac Chrome warm p95 and warm p50 regression.

Mac Chrome measurements and screenshots are pending the Mac VM lock.

Perf VM comparison completed under the perf-run lock. It alternated three origin/dev baseline rounds from branch base af202e1514955ddf0f8b4b3d2503c780d807ed84 with three head rounds at 0fa596ff27d6bb937cf759094f5bc724d9f9719a. The recorded load5 values at each run start were 1.84, 2.54, 3.07, 3.30, 3.59 and 3.71. Median warm first-visible p50/p95: baseline 99.3/216.4 ms; head 95.5/200.8 ms. Median cold first-visible p50/p95: baseline 96.4/273.2 ms; head 180.3/350.5 ms. All six profiles were saved. The three head benchmark commands exited 1 because the Perf VM profiles exceed the benchmark's 150 ms cold/warm p95 assertions; the user-set decision still depends on Mac Chrome warm p95 and warm p50 regression. Mac Chrome measurements and screenshots are pending the Mac VM lock.

kayg commented

2026-10-08 22:39:39 +00:00

Author

Owner

Post-merge Rust gates:

cargo clippy -p calternal-server --all-targets -- -D warnings passed:
Finished dev profile [unoptimized + debuginfo] target(s) in 33m 31s
The requested filtered command exited 0 but selected an ignored test (upstream runs live-app tests in separate processes):
test wire::tests::startup_serves_http_while_content_type_backfill_runs ... ignored, builds a live app with process-global plugin state; run by live_apps_run_in_separate_processes
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s
Executed the startup test once using its documented isolated mode. Result:
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 290 filtered out; finished in 22.48s

Mac Chrome comparison and screenshots remain queued for the Mac VM lock.

Post-merge Rust gates: - `cargo clippy -p calternal-server --all-targets -- -D warnings` passed: `Finished `dev` profile [unoptimized + debuginfo] target(s) in 33m 31s` - The requested filtered command exited 0 but selected an ignored test (upstream runs live-app tests in separate processes): `test wire::tests::startup_serves_http_while_content_type_backfill_runs ... ignored, builds a live app with process-global plugin state; run by live_apps_run_in_separate_processes` `test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s` - Executed the startup test once using its documented isolated mode. Result: `test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 290 filtered out; finished in 22.48s` Mac Chrome comparison and screenshots remain queued for the Mac VM lock.

kayg commented

2026-10-08 23:35:46 +00:00

Author

Owner

Mac VM access is still blocked by the shared /tmp/mac-bench.lock. The lock waiter has been active for about two hours and continues to print MAC_LOCK_WAITING; no Mac SSH, Chrome, or GUI session has been started outside the lock.

Post-merge gates are complete, the merge is committed, and the isolated startup regression passed. The Mac warm p50/p95 comparison and 12 screenshots remain pending because the owner rule requires exclusive VM access.

Mac VM access is still blocked by the shared `/tmp/mac-bench.lock`. The lock waiter has been active for about two hours and continues to print `MAC_LOCK_WAITING`; no Mac SSH, Chrome, or GUI session has been started outside the lock. Post-merge gates are complete, the merge is committed, and the isolated startup regression passed. The Mac warm p50/p95 comparison and 12 screenshots remain pending because the owner rule requires exclusive VM access.

kayg commented

2026-10-09 01:02:23 +00:00

Author

Owner

Search typing performance — #1425

Decision: REJECT (acceptance not established). The Mac VM lock remained unavailable through 01:00 UTC, so the required Mac Chrome timings and screenshots could not be collected. This is an evidence blocker, not a measured Mac performance failure. I did not update docs/perf/baseline.json.

Linux perf VM measurements

Three alternating rounds each; values are first-visible p50/p95 in milliseconds. Load averages recorded inside the lock were 1.84, 2.54, 3.07, 3.30, 3.59, 3.71.

Condition	Origin/dev rounds	Head rounds	Origin/dev median	Head median
Cold	92.7/273.2 (n=7); 96.4/351.9 (n=7); 137.1/235.8 (n=10)	180.3/350.5 (n=3); 210.3/260.3 (n=3); 147.3/411.2 (n=7)	96.4/273.2	180.3/350.5
Warm typing	110.5/216.4 (n=96); 99.3/236.4 (n=91); 95.4/187.3 (n=93)	95.5/200.8 (n=89); 76.0/176.9 (n=92); 107.0/205.9 (n=92)	99.3/216.4	95.5/200.8

Warm typing p50 on head was 3.8% faster than origin/dev on the perf VM. The head runs exited 1 where the profile's 150 ms p95 assertions fired. The Mac warm p50/p95 comparison is not measured.

Mac evidence

Mac Chrome warm p50/p95, three alternating rounds: not measured. The lock waiter repeatedly returned MAC_LOCK_WAITING; I did not open a Mac SSH, Chrome or GUI session without the lock.
The 12 requested 390/820/1440 light/dark screenshots after Cmd+K and mouse click: not captured or attached.
Because Mac p95 is unavailable, the 150 ms Mac criterion cannot be checked. No performance tuning or baseline update was made.

Commits and files

Head: a953928a57b0d299143978fa414e6a63042b3337
Commit: Merge origin/dev into search typing performance job
The Search implementation from 0fa596ff2 remains in the branch. Relevant files include apps/web/e2e/search-perf-1425.mjs, bench/search-typing-1425.sh, Search registry/server and focus modules/tests, crates/calternal-server/src/main.rs, crates/calternal-server/src/search_cancellation.rs, and the exact perf ledgers. The Mac runner patch was temporary and is not committed.
The perf comparison used branch-base origin/dev af202e1514955ddf0f8b4b3d2503c780d807ed84; current origin/dev had reworked the profile harness. This baseline choice was documented in an earlier issue comment.

Gates (verbatim output)

cargo fmt --check: exit 0, no output.

cargo clippy -p calternal-server --all-targets -- -D warnings:

Finished `dev` profile [unoptimized + debuginfo] target(s) in 33m 31s

Requested filtered command:

running 1 test
test wire::tests::startup_serves_http_while_content_type_backfill_runs ... ignored, builds a live app with process-global plugin state; run by live_apps_run_in_separate_processes
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s

The repository marks this live-app test ignored for normal runs. It passed once using the documented isolated mode:

test wire::tests::startup_serves_http_while_content_type_backfill_runs ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 290 filtered out; finished in 22.48s

bun run check:

perf-lint: PASS; 0 violations; 22544 scoped exceptions
svelte-check found 0 errors and 4 warnings in 2 files

bun run test:

 Test Files  301 passed (301)
      Tests  2170 passed (2170)
   Start at  23:21:33
   Duration  435.52s (environment 30%, import 25%, transform 24%, tests 15%, setup 6%)

cargo clean:

Removed 25250 files, 14.4GiB total

Remaining

The job time limit stopped further waiting. The next run needs to acquire /tmp/mac-bench.lock, run the six alternating Mac Chrome profiles, capture and attach the 12 screenshots, then apply the fixed decision rule. If ACCEPT, update and commit docs/perf/baseline.json; otherwise leave it unchanged. The worktree is clean, and build output was removed.

## Search typing performance — #1425 **Decision: REJECT (acceptance not established).** The Mac VM lock remained unavailable through 01:00 UTC, so the required Mac Chrome timings and screenshots could not be collected. This is an evidence blocker, not a measured Mac performance failure. I did not update `docs/perf/baseline.json`. ### Linux perf VM measurements Three alternating rounds each; values are first-visible `p50/p95` in milliseconds. Load averages recorded inside the lock were `1.84, 2.54, 3.07, 3.30, 3.59, 3.71`. | Condition | Origin/dev rounds | Head rounds | Origin/dev median | Head median | |---|---|---|---:|---:| | Cold | 92.7/273.2 (n=7); 96.4/351.9 (n=7); 137.1/235.8 (n=10) | 180.3/350.5 (n=3); 210.3/260.3 (n=3); 147.3/411.2 (n=7) | 96.4/273.2 | 180.3/350.5 | | Warm typing | 110.5/216.4 (n=96); 99.3/236.4 (n=91); 95.4/187.3 (n=93) | 95.5/200.8 (n=89); 76.0/176.9 (n=92); 107.0/205.9 (n=92) | 99.3/216.4 | 95.5/200.8 | Warm typing p50 on head was 3.8% faster than origin/dev on the perf VM. The head runs exited 1 where the profile's 150 ms p95 assertions fired. The Mac warm p50/p95 comparison is **not measured**. ### Mac evidence - Mac Chrome warm p50/p95, three alternating rounds: **not measured**. The lock waiter repeatedly returned `MAC_LOCK_WAITING`; I did not open a Mac SSH, Chrome or GUI session without the lock. - The 12 requested 390/820/1440 light/dark screenshots after Cmd+K and mouse click: **not captured or attached**. - Because Mac p95 is unavailable, the 150 ms Mac criterion cannot be checked. No performance tuning or baseline update was made. ### Commits and files - Head: `a953928a57b0d299143978fa414e6a63042b3337` - Commit: `Merge origin/dev into search typing performance job` - The Search implementation from `0fa596ff2` remains in the branch. Relevant files include `apps/web/e2e/search-perf-1425.mjs`, `bench/search-typing-1425.sh`, Search registry/server and focus modules/tests, `crates/calternal-server/src/main.rs`, `crates/calternal-server/src/search_cancellation.rs`, and the exact perf ledgers. The Mac runner patch was temporary and is not committed. - The perf comparison used branch-base `origin/dev` `af202e1514955ddf0f8b4b3d2503c780d807ed84`; current `origin/dev` had reworked the profile harness. This baseline choice was documented in an earlier issue comment. ### Gates (verbatim output) `cargo fmt --check`: exit 0, no output. `cargo clippy -p calternal-server --all-targets -- -D warnings`: ```text Finished `dev` profile [unoptimized + debuginfo] target(s) in 33m 31s ``` Requested filtered command: ```text running 1 test test wire::tests::startup_serves_http_while_content_type_backfill_runs ... ignored, builds a live app with process-global plugin state; run by live_apps_run_in_separate_processes test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s ``` The repository marks this live-app test ignored for normal runs. It passed once using the documented isolated mode: ```text test wire::tests::startup_serves_http_while_content_type_backfill_runs ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 290 filtered out; finished in 22.48s ``` `bun run check`: ```text perf-lint: PASS; 0 violations; 22544 scoped exceptions svelte-check found 0 errors and 4 warnings in 2 files ``` `bun run test`: ```text Test Files 301 passed (301) Tests 2170 passed (2170) Start at 23:21:33 Duration 435.52s (environment 30%, import 25%, transform 24%, tests 15%, setup 6%) ``` `cargo clean`: ```text Removed 25250 files, 14.4GiB total ``` ### Remaining The job time limit stopped further waiting. The next run needs to acquire `/tmp/mac-bench.lock`, run the six alternating Mac Chrome profiles, capture and attach the 12 screenshots, then apply the fixed decision rule. If ACCEPT, update and commit `docs/perf/baseline.json`; otherwise leave it unchanged. The worktree is clean, and build output was removed.

kayg commented

2026-10-09 01:04:38 +00:00

Author

Owner

Orchestrator decision: branch job/searchperf-1425 (a953928a5) REJECTED on the perf VM data alone, by the pre-set rule (no host may be >10% slower at p50): COLD first-visible p50 96 -> 180 ms (+87%), p95 273 -> 351 ms; warm only 3.8% faster. The server-first dispatch likely delays the first local results on a cold window. Not merging. The focus-ring fix after Cmd+K (commit 926c6308e) is UI and will be ported separately by a Sonnet worker. Next step for #1425: profile cold first-visible on dev and keep local results first.

Orchestrator decision: branch job/searchperf-1425 (a953928a5) REJECTED on the perf VM data alone, by the pre-set rule (no host may be >10% slower at p50): COLD first-visible p50 96 -> 180 ms (+87%), p95 273 -> 351 ms; warm only 3.8% faster. The server-first dispatch likely delays the first local results on a cold window. Not merging. The focus-ring fix after Cmd+K (commit 926c6308e) is UI and will be ported separately by a Sonnet worker. Next step for #1425: profile cold first-visible on dev and keep local results first.

kayg referenced this issue from a commit

2026-10-09 06:04:53 +00:00

Merge job/searchring-1425 (#1425)

kayg referenced this issue

2026-10-09 06:56:01 +00:00

Search e2e opening shortcut asserts an obsolete input modality #1505

kayg referenced this issue from a commit

2026-10-09 11:11:17 +00:00

Test Search opens without a focus ring after shortcut and click

kayg referenced this issue from a commit

2026-10-09 11:11:17 +00:00

Keep focus on the surface a phone sidebar action opens