kayg/calternal-v0

Archived

Watch

Fork 0

Calendar: reduce busy opening latency with bounded source request fan-out #1232

Open

opened 2026-10-06 21:31:46 +00:00 by kayg · 3 comments

kayg commented

2026-10-06 21:31:46 +00:00

Owner

Unchanged Calendar baseline: Week opening p50 / p95 / max 4943.63 / 6272.14 / 6272.14 ms; Month 2971.95 / 4298.34 / 4298.34 ms. Independent Task reads improved Month to 2669.95 / 3607.41 ms (10.16% p50 gain), but regressed Week to 6453.27 / 11272.06 ms. Candidate e1f5b02a8 was reverted by 8f6cde19a. Do not retain the global overlap or infer that a date-span threshold is already verified.

Resource timing in the earlier ready-paint phase recorded /api/v1/calendar/items at 7897.5 ms. Client readItemPages uses dependent cursors, at most 20 × 1000 items; page requests cannot run independently. The complete projection waits for Items and Tasks by #549/#589. Week loadChunk starts multiple seven-day requests; adding a third source per chunk increases potential request fan-out. Month uses one wide range. Server read_batch in crates/plugins/calendar/src/items.rs uses indexed candidate rows through a UNION and cursor. No server flamegraph or query plan was captured; neither a full scan nor a lock bottleneck is proven. Investigate bounded concurrent source scheduling and the real server query before changing the complete-projection contract.

Evidence: docs/perf/2026-10-06-1124-round2.md, runs/2026-10-06-1124-round2-calendar-io.json; source-attributed scroll follow-up #1230. Retain only ≥10% p50 gain without p95 regression on affected views. SLOW-only performance finding; no crash or data-loss finding.

Performance follow-up to #1124 round 2. Busy Calendar opening remains slow on the shared perf VM, Chromium 4× CPU throttle, macOS platform, 5,000 Files / 240 asserted Logs / 121 asserted provider Events, full HDD scope (8 ms, 200 IOPS, 150 MB/s), five interleaved pairs under perf-run. Unchanged Calendar baseline: Week opening p50 / p95 / max 4943.63 / 6272.14 / 6272.14 ms; Month 2971.95 / 4298.34 / 4298.34 ms. Independent Task reads improved Month to 2669.95 / 3607.41 ms (10.16% p50 gain), but regressed Week to 6453.27 / 11272.06 ms. Candidate e1f5b02a8 was reverted by 8f6cde19a. Do not retain the global overlap or infer that a date-span threshold is already verified. Resource timing in the earlier ready-paint phase recorded /api/v1/calendar/items at 7897.5 ms. Client readItemPages uses dependent cursors, at most 20 × 1000 items; page requests cannot run independently. The complete projection waits for Items and Tasks by #549/#589. Week loadChunk starts multiple seven-day requests; adding a third source per chunk increases potential request fan-out. Month uses one wide range. Server read_batch in crates/plugins/calendar/src/items.rs uses indexed candidate rows through a UNION and cursor. No server flamegraph or query plan was captured; neither a full scan nor a lock bottleneck is proven. Investigate bounded concurrent source scheduling and the real server query before changing the complete-projection contract. Evidence: docs/perf/2026-10-06-1124-round2.md, runs/2026-10-06-1124-round2-calendar-io.json; source-attributed scroll follow-up #1230. Retain only ≥10% p50 gain without p95 regression on affected views. SLOW-only performance finding; no crash or data-loss finding.

kayg referenced this issue

2026-10-06 21:41:34 +00:00

PERF: Money import preview of a 15 MB / 25k-transaction Actual export takes 30–45 s #1124

kayg commented

2026-10-06 22:06:00 +00:00

Author

Owner

The scoped follow-up was tested and rejected. Source 7e2eb76b9 keeps the original seven-day Week Task pipeline and overlaps only the 28–42-day window. Five paired opens: Week p50/p95 7312.59/7602.58 → 6766.77/13383.60 ms; Month 3978.13/4831.62 → 4353.00/5031.05 ms. 9547e53dd reverts it. This does not reproduce the earlier Month gain. Because Week scheduling stayed the same, extra Task fan-out alone does not prove the tail cause. Capture server stacks/query plans and check equal asset warm-up; fixture registration serves the first build. No sample was removed. Raw results: docs/perf/runs/2026-10-06-1124-round2-calendar-month.json. Final retained Files/Search code passes check and all 1980 tests; Calendar remains unfinished at the time limit.

The scoped follow-up was tested and rejected. Source 7e2eb76b9 keeps the original seven-day Week Task pipeline and overlaps only the 28–42-day window. Five paired opens: Week p50/p95 7312.59/7602.58 → 6766.77/13383.60 ms; Month 3978.13/4831.62 → 4353.00/5031.05 ms. 9547e53dd reverts it. This does not reproduce the earlier Month gain. Because Week scheduling stayed the same, extra Task fan-out alone does not prove the tail cause. Capture server stacks/query plans and check equal asset warm-up; fixture registration serves the first build. No sample was removed. Raw results: docs/perf/runs/2026-10-06-1124-round2-calendar-month.json. Final retained Files/Search code passes check and all 1980 tests; Calendar remains unfinished at the time limit.

kayg referenced this issue

2026-10-06 22:06:00 +00:00

PERF: Money import preview of a 15 MB / 25k-transaction Actual export takes 30–45 s #1124

kayg commented

2026-10-08 04:02:52 +00:00

Author

Owner

Additional diagnostic evidence from #1400, job/bash3-interop: a local production SPA with 1,000 file-seeded Journal entries at 09:00–11:00 on one day kept a stable 17,100,000-byte browser heap during a five-minute read soak. A PerformanceObserver started after the first real title became visible recorded long tasks of 5177, 1498, 1056, 1024 and 795 ms. Server RSS fell from 319,420 to 158,688 KiB; server CPU was 32.23 seconds over the soak. Shared host load was 16.71/24.00/23.58 around the preceding profile. No main-thread trace or source attribution was captured, so these are SLOW-only diagnostics, not a proven new regression. Evidence: artifacts/bash3-interop/final-live.json and final-live-second.log; fixture and runner in final-live.mjs. Linking here rather than creating a duplicate Calendar opening performance issue. UI/core is outside this DAV-only job.

kayg referenced this issue

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

Bug bash round 3: interop #1400

kayg commented

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

Author

Owner

API measurement from audit #1374, branch head ace13fe6c, on the perf VM with the shared release server from d395b6e25:

GET /api/v1/notes/tasks/day returned p50 / p95 / max 111.77 / 137.00 / 138.02 ms over 20 requests. The response was 20,189,645 bytes and contained 43,804 Task-day projections from a 1,000-Task fixture. The handler is crates/plugins/notes/src/tasks_api.rs::by_day: it reads indexed Tasks, then visits every Task for each date in the requested window and serializes matching day entries. The exact query plan will be in the #1374 report. This is the server Task source cost relevant to the Calendar opening profile here; it is not a Calendar paint measurement.

API measurement from audit #1374, branch head `ace13fe6c`, on the perf VM with the shared release server from `d395b6e25`: `GET /api/v1/notes/tasks/day` returned p50 / p95 / max 111.77 / 137.00 / 138.02 ms over 20 requests. The response was 20,189,645 bytes and contained 43,804 Task-day projections from a 1,000-Task fixture. The handler is `crates/plugins/notes/src/tasks_api.rs::by_day`: it reads indexed Tasks, then visits every Task for each date in the requested window and serializes matching day entries. The exact query plan will be in the #1374 report. This is the server Task source cost relevant to the Calendar opening profile here; it is not a Calendar paint measurement.

Commenting is not possible because the repository is archived.

No labels

No milestone

No project

No assignees

1 participant

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

kayg/calternal-v0#1232

No description provided.

Rows
Columns