2 Commits

Include renames

Author	SHA1	Message	Date
3 people	1d9a563d1a	test(performance): count startup phases and SQL statements for the J1 launch journey (#1715) ... * test(performance): count startup phases and SQL statements for the J1 launch journey Implements plan item A2. With IPTVNATOR_PERF_CAPTURE=1 the main process keeps named counters and registers a main-only performance:read-counters IPC handler; without the flag nothing is counted and the handler does not exist. - debug-trace.ts owns the registry; traceStartupPhase replaces the trace('startup', ...) sites and counts main.startupPhases. - The database worker counts executed statements through better-sqlite3's Statement prototype (the verbose callback expands every statement and made bulk inserts 2-4x slower) and posts the count over its message port, flushed before every other worker message. The main-thread shared connection is counted through a new connection observer in the shared database library. - The first main window freezes main.modulesRegisteredBeforeWindow at creation and main.sqlStatementsBeforeReadyToShow at ready-to-show. - The journey gate drops the ready-to-show that Electron emits for the about:blank detour, so the app sees the real document's first paint, and taps the counters handler; the J1 record reads both counters after the renderer probe completes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(database): require one SQL statement per exec during initialization The performance capture counts one exec call as one statement, because SQL cannot be split reliably in the counter (trigger bodies contain semicolons). The historical-upgrade driver now wraps exec on every connection initDatabase opens and fails on a batch, so that counting assumption holds for the fresh profile and all historical schemas. Documents the definition in the counter and the architecture docs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(performance): count SQL statements only for the launch journey Codex review: the M3U import, refresh-cancellation and Xtream benchmarks also run with IPTVNATOR_PERF_CAPTURE=1, so the statement hook wrapped every row of their bulk inserts and changed what they measure. SQL counting now also needs IPTVNATOR_PERF_COUNT_SQL=1, which only the launch journey sets; a harness test fails if another source sets it. Startup phases, the window snapshot and the read handler stay on the capture flag. Without SQL counting no ready-to-show listener is attached, so a zero is never reported for statements nobody counted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: 4gray <fourgray@proton.me> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 21:01:26 +02:00
3 people	0f1cad4b16	test(performance): add the J1 launch-to-usable journey benchmark (#1698) ... * test(performance): add the J1 launch-to-usable journey benchmark Implements plan items A1, A3 (J1 only) and the minimal A4 from .plans/2026-09-25-performance-journeys-ratchet.md. - journey-renderer-probe.ts: init-script probe counting DOM mutations, layout shifts and long tasks until the first source card is visible on /workspace with the splash removed; unit-tested with jsdom fixtures. - journey-main-ipc-capture.ts: counts bridge invocations from the preload's renderer-API trace channel up to a sentinel call the probe fires, so the IPC counter is exact without touching production code. - launch.journey.ts + playwright.journeys.config.ts: seeded profile (one M3U source, one Xtream portal on the loopback mock), one warm-up and five measured iterations, fresh process and data directory each, writing dist/performance/journeys/<timestamp>/summary.json with exact counters and P50/P90 wall-clock. - Nx target electron-backend-e2e:journeys and root script perf:journeys. - docs/architecture/performance-journeys.md, README, context and validation map entries. renderer.cdTicksToFirstCard and main.sqlStatementsBeforeReadyToShow are reported as unavailable with the reason instead of being faked. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(performance): gate the renderer load so the probes never race startup Review follow-up for #1698. - journey-renderer-gate.cjs: a main-process hook loaded with `-r` (the mechanism Playwright uses for its own loader) makes the first loadFile/loadURL navigate to about:blank and holds the real load until the test releases it. Playwright reports no page before a navigation commits, so this is what lets the renderer probe be registered on the page before the real document exists; the IPC capture is installed before the release too. A safety timeout releases the gate on its own and marks the iteration invalid. Unit-tested with a fake BrowserWindow. - launch-journey-app.ts: registers the probe on the parked page, releases the gate, waits for the real document to commit, fails fast when the probe is missing, and refuses an iteration whose gate timed out, saw a second load, or released before the probe was in place. - journey-renderer-probe.ts: entries delivered live after the terminal batch are buffered and filtered by the same cutoff as queued ones, and the cutoff is sampled in a timer queued from the first rAF, i.e. after the card's frame is painted, so the render task's long task and layout shift are consistently included. - launch-journey-record.ts: layoutShiftScore rounded to three decimals; a 0.0001 shift flipped in and out of the cutoff between iterations. - playwright.journeys.config.ts: reuse a mock server left on the journeys port locally (its fixtures are deterministic); CI still starts its own. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(performance): validate the journey gate after the probe completes Codex follow-up on #1698: the gate state returned by release() cannot see a reload or recovery navigation that happens before the first card. Re-read the live state once the renderer probe has finished and validate that instead, so an iteration spanning an extra navigation is rejected. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test(performance): fail an iteration whose performance observers were unavailable Codex follow-up on #1698: a renderer that cannot observe layout-shift or longtask entries used to pass the probe with zero counters, which a ratchet could not tell apart from a genuine zero. The probe assertion now rejects such an iteration and names the missing observer. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: 4gray <fourgray@proton.me> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-26 19:18:19 +02:00