perf: stop scanning arrays where a lookup does, on large builds - #401
Merged
nGervasyuk merged 2 commits intoAug 23, 2026
Merged
Conversation
This was referenced Aug 21, 2026
nGervasyuk
force-pushed
the
perf/large-build-interactions
branch
2 times, most recently
from
August 23, 2026 06:36
65d25c4 to
4bb14ed
Compare
Selecting every run of a build is one click, and each of the places that asks whether a run is selected walked the array of selected ids: the grouped selection model and card count do it per run of every group, the bulk operations do it per row, and a card does it per run behind it. With ten thousand runs selected that is a hundred million comparisons per render. Index the selected ids in a set and read membership off it. Measured in Chromium on a 10 000 run build: select all rows 265 ms -> 90 ms select all cards, grouped 306 ms -> 120 ms The card grid takes the set itself rather than the array, so it does not rebuild one per render. The tag filter's options also stopped building an array per run while collecting the values on offer — thousands of throwaway allocations on every keystroke.
The list republishes the order the details dialog navigates on every grid state change, which with thousands of runs means a fresh array of that many ids landing in the context — and every consumer re-rendering — even when the order is identical. Compare before storing, and keep the previous array when nothing moved.
nGervasyuk
force-pushed
the
perf/large-build-interactions
branch
from
August 23, 2026 06:42
4bb14ed to
ea41938
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, list interactions cost hundreds of milliseconds each. CPU profiles taken in Chromium (10 000 runs, 500 screens × 20 locales) point at linear scans that run per row:
Change
Setand read membership off it; the card grid takes the set rather than the array, so it does not rebuild one per renderMeasurements
Chromium, 10 000 runs, same harness before and after:
No hot frame is left in the profiles — what remains is React and MUI render work spread thin.
I also measured handing the data grid only the page it displays, since the list already filters, sorts and paginates itself: it moved opening a build from 521 ms to 486 ms and left the filter interactions unchanged, so it is not worth the change in sorting, selection and published-order semantics that it would need.
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.