From e3d7cc869bd6be963eb1c075f689d1d27a1bc159 Mon Sep 17 00:00:00 2001 From: 4gray Date: Wed, 30 Sep 2026 07:22:21 +0200 Subject: [PATCH] docs(perf): record the runner's settled layout-shift measurement Co-Authored-By: Claude Opus 5.5 --- docs/architecture/performance-journeys.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/docs/architecture/performance-journeys.md b/docs/architecture/performance-journeys.md index bc5fba189..cf3a0d660 100644 --- a/docs/architecture/performance-journeys.md +++ b/docs/architecture/performance-journeys.md @@ -179,6 +179,12 @@ down. Something 316 px tall above it is removed and inserted again during startup, a flicker #1738 did not cover. The counter is working as intended; the flicker is a separate fix. +On the Linux CI runner (`Performance journeys` job of #1756, run +36618062068) the same flicker is a race: the measured iterations read +`[0, 0, 0.235, 0, 0]` (`stable: false`, every window `quiet` about 540 ms +after the first card), and the one hit shows the same two 316 px moves of +the recent-sources rail. + #### Main-process counters With `IPTVNATOR_PERF_CAPTURE=1`, which the journey sets, @@ -650,10 +656,10 @@ in all eighteen runner iterations; the `spawnToFirstCardMs` P50 ranged from 1,401 to 1,674 ms. All four stay evidence for now. Runner counters also differ from a Mac (12 and 571 there, the fast path without the Linux-only `getWindowState` call), so take J1 baseline values from the runner only. -`renderer.layoutShiftScoreSettled` has no baseline either: it has only been -measured on a Mac so far (see [Settle window](#settle-window)), and a -baseline needs the runner's number once the dashboard flicker it reports -is fixed. +`renderer.layoutShiftScoreSettled` has no baseline either: the runner reads +it as `stable: false` because the dashboard flicker it reports is a race +there (see [Settle window](#settle-window)). Add the runner's number once +that flicker is fixed and the counter is deterministic. ## Charset parse benchmark