From a772f356cbbd5df0da6291e76248e60cadd4c559 Mon Sep 17 00:00:00 2001 From: tannevaled Date: Sat, 10 Oct 2026 22:01:43 +0200 Subject: [PATCH] docs: correct round 168's shared-cause guess for the other slow bench pages Checked foundation.zurb.com (24.8s in the 500-page run, untouched by this round's live testing) directly rather than assume the font-face fix (round 168, PR #267) also explains it: still ~40s after that fix, but DisableJS=true drops it to ~6.2s on the same page -- its slowness is JS-settle-related, not the font-face-slot bug round 168 fixed. cs.cmu.edu itself could not be cleanly re-measured: a careful single re-check well after the fix merged still showed ~45s, consistent with this round's own earlier live testing having triggered the origin's own throttling (escalating response times observed before the fix even shipped), which outlasted the session rather than the fix being ineffective -- the deterministic local test (already in PR #267) remains the real evidence for it. Co-Authored-By: Claude Sonnet 5 --- FIDELITY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIDELITY.md b/FIDELITY.md index 25d5139..8bbc4fa 100644 --- a/FIDELITY.md +++ b/FIDELITY.md @@ -27,7 +27,7 @@ The 500-page run relaunched at the end of round 167 (both crash fixes in place) - **Fixed**: `LoadFontFaces`'s per-slot loop now fires every DISTINCT candidate concurrently (deduped by a new `srcsKey` — the same src list parsed twice, e.g. the same stylesheet named twice, still fetches once) and picks the lowest-declaration-order success after they all finish, instead of walking the list waiting for each failure in turn. `e.Client`'s existing per-host semaphore (`maxPerHostConcurrency`, round 57/58, left at 2 — the round-152/153-measured value, re-confirmed still right for Wikimedia, not re-opened by this round) still bounds real network concurrency, so this is a bounded, not unlimited, speedup: candidates now batch through that cap rather than waiting out every predecessor's own fetch one at a time. - **Test**: `TestLoadFontFacesTriesSlotCandidatesConcurrentlyNotSequentially` — a local server with 5 slow-then-500 candidates plus 1 fast-success candidate declared LAST in one slot, deliberately shaped like the live cs.cmu.edu case. Stash-verified: ~460ms with the fix (bounded by the per-host cap, confirmed deterministic across 3 runs) vs ~760ms on the unfixed code (sequential), a measured, reproducible, and reliably-separated difference, not assumed from the live site alone (which could not be cleanly re-measured after this round's own repeated testing had, by its own escalating response times, visibly triggered the origin's own rate-limiting/anti-scraping defenses — an honest limitation of live-site verification for this specific fix, mitigated by the deterministic local-server test instead). - **Coverage**: `fontfaces.go`'s `LoadFontFaces` and the new `srcsKey` both land at 100%; the top-level `engine` package moves from a pre-existing 96.1% baseline (confirmed via `git stash`, unrelated gaps) to 96.2% — no regression. -- **Not fixed this round, flagged honestly**: `unicode-range` itself remains unmodelled (this fix removes the serialization cost of the collision, not the collision — all five rules still compete for one slot, and whichever succeeds first wins for the WHOLE family+weight regardless of which glyphs it actually covers; a page relying on Font Awesome's REAL icon-subset behavior could still render the wrong glyphs, just not slowly). The other ~9 slow pages from this round's bench run were not individually profiled — `cs.cmu.edu`'s own shape (several same-weight legacy-shim font-face rules hitting a consistently-erroring endpoint) is a plausible but UNCONFIRMED shared cause; re-measuring the full 500-page corpus once this fix lands is the natural next check. +- **Not fixed this round, flagged honestly**: `unicode-range` itself remains unmodelled (this fix removes the serialization cost of the collision, not the collision — all five rules still compete for one slot, and whichever succeeds first wins for the WHOLE family+weight regardless of which glyphs it actually covers; a page relying on Font Awesome's REAL icon-subset behavior could still render the wrong glyphs, just not slowly). `cs.cmu.edu` itself could not be cleanly re-measured after this fix landed — the live-site contamination described above persisted (still ~45s on a careful single re-check well after the fix merged), consistent with the origin's own throttling outlasting this session rather than the fix being ineffective (the deterministic local test is the real evidence it works). Checked ONE other slow page from the same bench run, `foundation.zurb.com` (24.8s in the run, not yet touched by any of this round's live testing, so uncontaminated): still ~40s after the fix, and — checked directly rather than assumed — `DisableJS=true` dropped it to ~6.2s on the SAME page, meaning its slowness is JS-settle-related, NOT the font-face bug this round fixed. **Correcting the round's own earlier guess**: `cs.cmu.edu`'s shape is not a shared cause across the other ~9 slow pages; at least `foundation.zurb.com` has a distinct, unrelated, JS-driven cause, still open for a future round. ## 2026-10-09 (round 167) — the interrupted 500-page bench run (round 166's own queued work) found a second real crash: a lone CSS Grid item using `grid-row:1 / -1` with no explicit row template panicked on an empty row-offset slice (engine#266, patch)