Repository navigation
perf(panel,ui): stop forcing a whole-window layout on every draw and DOM change - #4296
Merged
Merged
Conversation
…DOM change A profile of the panel on a long agent transcript (about 53k DOM nodes) spent about 21% of the main thread in three synchronous layouts, each one laying out the whole window: - column-dock re-read every docked box after every DOM change under the shell, and re-observed every box each time. It now reads once per frame, follows the column and its parts afresh only when they change, and writes --column-dock on the root, and --floating-card, only when the value changes. - The skill and mention pickers measured their field during every draw of every composer. They now measure only while their list is open. - ChoiceBar re-placed its thumb after every draw. It now does so only when the choice or the options standing change; resizes stay with its ResizeObservers. A transcript followed afresh is re-sent whole. applyMessagesPage now keeps a message heard again unchanged, and answers what was held when a page changes nothing, so the rows memoized on a message's identity skip the redraw. Co-authored-by: luke-agent[bot] <339870089+luke-agent[bot]@users.noreply.github.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This was referenced Oct 21, 2026
This branch was successfully deployed
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
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.
Charles asked why Luke was slow and laggy today, then to fix the cheap 90/10 part. This PR is that part.
What the profile showed
I profiled Charles's panel renderer, built from
mainat03b922186, while it ran.getBoundingClientRect.About 21% of the main thread went to three synchronous layouts. Each one lays out the whole window:
column-dock.tsMutationObserverre-measured every docked box after every DOM change under the shell, and re-observed every box each time. Since #4046 it also writes--column-dockon:root.skill-picker.tsx(and the same code inmention-picker.tsx)choice-bar.tsxuseLayoutEffecthad no dependency list, so the thumb was re-placed after every draw.What changed
--column-dockand--floating-cardare written only when the value changes. A hidden window no longer lays out at all.applyMessagesPage: a message heard again unchanged keeps its held object, and a page that changes nothing returns the held array.Left for later
These are the larger fixes, out of this PR's scope:
Tests
applyMessagesPage: a page that repeats what is held keeps the held messages and the held array. This fails on the old join.17 nearby test files (349 tests) pass, and the panel, ui and features typechecks pass. I ran no live before/after measurement on the Mac.
Made with Luke