Calendar Week: investigate increased raster wall duration in the 60-day scroll profile #1026

New issue

Open

opened 2026-10-03 19:17:02 +00:00 by kayg · 1 comment

kayg commented

2026-10-03 19:17:02 +00:00

Owner

During #1018, one paired locked perf-test VM run of the same real 650-day / 7,200-Log fixture showed a raster duration increase in the 1440 px native wheel 60-day burst.

Before SPA: bd11bacb51 (origin/dev). After SPA: f1f9ea9fe. Chrome 153.0.8010.12, CPU throttle off, same server binary and Home, /root/perf.lock held for each measured session. Recorded starting load: 0.08 / 0.00.

Summed RasterTask wall duration: 1,135.487 → 1,467.895 ms (+29.3%). Raster tasks overlap on threads; this sum is not CPU time.
Paint duration: 210.207 → 155.688 ms (-25.9%).
Renderer task CPU: 3.024 → 2.281 s (-24.6%).
Frame p95: 200.0 → 150.1 ms; still above #1018's 16.7 ms target.
Layout passes: 473 → 128.

This is one before/after pair. Investigate why raster work rose before setting a raster budget. Retained columns use fixed absolute positions inside native-width paint anchors; the number of mounted Week columns fell from 21 to 11. No cause is established yet. Do not infer a repeatable regression from the wall-duration sum alone.

Evidence: the before/after production traces and results are attached to #1018, and the summary is in docs/perf/week-scroll-1018.json and docs/perf/week-scroll-1018.md. The fixture SHA is 2a21af28cbe71ec36beb11e17496c2c5f3a9a8216a66712f32a139482cc85ac2. Repeat on the perf VM under /root/perf.lock; use the same fixture and saved builds with bench/week-scroll-1018.mjs --compare. No build must run on that VM.

During #1018, one paired locked perf-test VM run of the same real 650-day / 7,200-Log fixture showed a raster duration increase in the 1440 px native wheel 60-day burst. Before SPA: bd11bacb5189d39176e7cd48d5e977f1694321c1 (origin/dev). After SPA: f1f9ea9fe. Chrome 153.0.8010.12, CPU throttle off, same server binary and Home, /root/perf.lock held for each measured session. Recorded starting load: 0.08 / 0.00. - Summed RasterTask wall duration: 1,135.487 → 1,467.895 ms (+29.3%). Raster tasks overlap on threads; this sum is not CPU time. - Paint duration: 210.207 → 155.688 ms (-25.9%). - Renderer task CPU: 3.024 → 2.281 s (-24.6%). - Frame p95: 200.0 → 150.1 ms; still above #1018's 16.7 ms target. - Layout passes: 473 → 128. This is one before/after pair. Investigate why raster work rose before setting a raster budget. Retained columns use fixed absolute positions inside native-width paint anchors; the number of mounted Week columns fell from 21 to 11. No cause is established yet. Do not infer a repeatable regression from the wall-duration sum alone. Evidence: the before/after production traces and results are attached to #1018, and the summary is in docs/perf/week-scroll-1018.json and docs/perf/week-scroll-1018.md. The fixture SHA is 2a21af28cbe71ec36beb11e17496c2c5f3a9a8216a66712f32a139482cc85ac2. Repeat on the perf VM under /root/perf.lock; use the same fixture and saved builds with bench/week-scroll-1018.mjs --compare. No build must run on that VM.

kayg referenced this issue

2026-10-03 19:20:01 +00:00

PERF: Week view horizontal scrolling is laggy with real-size data (7k entries) #1018

kayg referenced this issue

2026-10-03 20:52:26 +00:00

PERF: Week view horizontal scrolling is laggy with real-size data (7k entries) #1018

kayg commented

2026-10-05 06:36:38 +00:00

Author

Owner

Locked perf VM run, 2026-10-05. The profile used Chrome 153.0.8010.12, the 650-Day / 7,200-Log fixture, and /root/perf.lock. Load was 0.02 / 0.01 / 0 at the start. The web source was d6db9759f; the shared release API server was bff78498f230e805ab14686e4e827f415a7c0424 (SHA-256 bd8c76bf064fd1c7365af5f0e96f71ebf1cd4e6cebd481d51dd82f5adc088dc3).

The 1440 px, 60-day wheel sample measured frame p50/p95 of 50.0 / 133.3 ms, 11.64 s browser CPU, 808 → 910 MiB browser RSS, and 16 long tasks (maximum 271 ms). The existing 50 ms p95 guard failed.

The stored round 4 result measured 16.8 ms p95, but it used server commit cb1b3f6e7; this run used bff78498f. The server versions differ, so this is not a matched comparison and does not establish a cause. The shared paint-state probe did confirm the gutter clip, opaque fill, and five blur layers after real horizontal gestures. Full metrics and limits: docs/perf/mchrome-1084.md.

Locked perf VM run, 2026-10-05. The profile used Chrome 153.0.8010.12, the 650-Day / 7,200-Log fixture, and `/root/perf.lock`. Load was 0.02 / 0.01 / 0 at the start. The web source was `d6db9759f`; the shared release API server was `bff78498f230e805ab14686e4e827f415a7c0424` (SHA-256 `bd8c76bf064fd1c7365af5f0e96f71ebf1cd4e6cebd481d51dd82f5adc088dc3`). The 1440 px, 60-day wheel sample measured frame p50/p95 of 50.0 / 133.3 ms, 11.64 s browser CPU, 808 → 910 MiB browser RSS, and 16 long tasks (maximum 271 ms). The existing 50 ms p95 guard failed. The stored round 4 result measured 16.8 ms p95, but it used server commit `cb1b3f6e7`; this run used `bff78498f`. The server versions differ, so this is not a matched comparison and does not establish a cause. The shared paint-state probe did confirm the gutter clip, opaque fill, and five blur layers after real horizontal gestures. Full metrics and limits: `docs/perf/mchrome-1084.md`.

kayg referenced this issue

2026-10-05 06:46:41 +00:00

Mobile: sheet top band is back; needs iOS presentation sheet header with dynamic title and progressive blur #1084

kayg referenced this issue

2026-10-05 06:46:43 +00:00

Mobile: tab bar progressive blur disappears during horizontal day swipe #1082

kayg referenced this issue

2026-10-05 07:31:07 +00:00

Mobile: sheet top band is back; needs iOS presentation sheet header with dynamic title and progressive blur #1084

kayg referenced this issue

2026-10-05 07:31:10 +00:00

Mobile: tab bar progressive blur disappears during horizontal day swipe #1082