perf: read the published run order by id instead of scanning it - #400
Merged
nGervasyuk merged 1 commit intoAug 23, 2026
Merged
Conversation
This was referenced Aug 21, 2026
The details dialog turns the order the list publishes into its own run array, and it did so by scanning that array: once per run to filter, then twice per comparison while sorting. On a build of ten thousand screenshots that is a hundred million comparisons for the filter alone, and the sort makes it far worse. It also runs whether the dialog is open or not, and on every list change — switching view, grouping variations, picking a tag filter — so the whole page stalled for over a second on each interaction. Measured in Chromium on a 10 000 run build: 1.4 s of the 1.9 s spent on a Group variations toggle was this one memo. Index the published order in a Map and read positions off it: open a build 1190 ms -> 544 ms switch to cards 755 ms -> 118 ms group variations 618 ms -> 100 ms The index of the run on screen is already memoised right below, so the render no longer scans for it a second time.
nGervasyuk
force-pushed
the
fix/dialog-order-quadratic
branch
from
August 23, 2026 06:15
73b8b8f to
71d71aa
Compare
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Reviewing a build of ~10 000 screenshots, every interaction with the list froze the page for over a second: opening the build, switching to the card view, toggling Group variations, picking a tag filter.
The API was idle throughout (0% CPU, list served in 160 ms), so this is all in the browser. A CPU profile taken in Chromium on a 10 000 run build points at one place — 1422 ms of the 1858 ms spent on a single Group variations toggle:
That memo turns the order the list publishes (
filteredSortedTestRunIds) into the dialog's own run array by scanning that array:includesonce per run to filter, thenindexOftwice per comparison while sorting. With 10 000 runs the filter alone is 10⁸ comparisons, and the sort is far worse.Two things make it hurt:
if (!selectedTestRun) return nullguard sits below the hooksChange
Index the published order in a
Maponce and read positions off it, so filtering and sorting are lookups rather than scans. The render also no longer scans for the current run's index a second time — that index is already memoised right below.Measured with the same harness in Chromium, 10 000 runs, 500 screens × 20 locales:
The hotspot disappears from the profile entirely; what is left is idle time and
groupTestRunsat ~9 ms.Behaviour is unchanged — the dialog still walks the runs in the order the list publishes, which the existing arrow-navigation integration tests cover. Unit (19) and Playwright (84) suites pass.
Nothing to configure. Independent of the other open frontend PRs (#397, #398, #399, #400, #401) — verified that they all merge onto
masterin sequence without conflicts, in any order.