perf(editor): batch doc-comment zone measurement and color the viewport on open - #1314
Open
bobzhang wants to merge 1 commit into
Open
perf(editor): batch doc-comment zone measurement and color the viewport on open#1314bobzhang wants to merge 1 commit into
bobzhang wants to merge 1 commit into
Conversation
…rt on open Opening a large MoonBit file in the desktop stalled for seconds before the first paint, and the visible lines colored only after an idle callback. Profiling the browser bundle in Chromium showed the lexer and background tokenizer were never the cost (20k lines tokenize in ~17 ms); the stall was the rich `///` doc-comment feature measuring every comment ViewZone in the DOM one at a time, each with its own forced layout and ViewZone transaction. - Measure comment zones through a per-editor `MarkdownCommentMeasureBatch`: one pass per animation frame that reads directly measurable heights, then shows every hidden zone invisibly at once, reads all heights, restores styles, and reports; the contribution publishes the reported heights in a single `change_view_zones` transaction. - Call `Viewer::handle_initialized` from the desktop after `set_model`, as the reference workbench does, so the viewport's tokens are computed before the first paint instead of waiting for `requestIdleCallback`. - Let the viewport-priority pass tokenize a range that ends exactly at the tokenization frontier; the ported `<=` early return left a one-line first visible range (a lone header comment before a hidden doc comment) plain. Measured in Chromium through the desktop browser bundle, click to colored viewport: 10k lines 538 ms -> 209 ms, 20k lines 1204 ms -> 370 ms, 40k lines 3577 ms -> 567 ms. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BGkUVgkpJqT3TQTu2hN5YW
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
1 participant
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
Opening a large
.mbtfile in the desktop stalled for seconds before the first paint, and the visible lines were colored only after a later idle callback.Root cause
The MoonBit lexer and the Monaco-style background tokenizer are not the cost: 20k lines tokenize end to end in about 17 ms headless. A Chromium CPU profile of the desktop browser bundle attributed the stall to the rich
///doc-comment feature. Every doc-comment block becomes a ViewZone, and each zone's height was measured on its own (display:block,getBoundingClientRect,offsetHeight, restore), so a 20k-line file forced about 1500 synchronous layouts inside one animation frame, then applied each height in its own ViewZone transaction that re-rendered all zones. The viewport's coloring waited onrequestIdleCallback, which could not fire until that task ended.Two smaller issues compounded it:
Viewer::handle_initializedafterset_model, unlike the reference workbench, so the viewport's tokens were never requested synchronously and even small files painted plain first.end <= first_invalidearly return, which skips a range ending exactly at the tokenization frontier. A one-line first visible range (a header comment followed by a hidden doc comment) stayed plain until the idle pass.Changes
editor/internal/viewer/contrib/markdown_comments/browser: newMarkdownCommentMeasureBatch. One measurement pass per animation frame: direct reads first, then all style writes for hidden zones, then all reads, then restores, then the height callbacks and a singleon_pass_complete.observe_sizenow takes the batch. A test asserts the write, read, restore order across zones, the single frame, the single completion, and disposal.editor/internal/viewer/code_editor_widget/markdown_comments_contribution.mbt: the contribution owns one batch per editor and publishes the heights reported by a pass in onechange_view_zonestransaction.desktop/frontend/fileeditor/editor_panel.mbt: callhandle_initializedafter the model, restored view state, and initial fold policy are in place, matchingTextFileEditor.setInputand the reference shell.editor/viewer/common/model/text_model_tokens.mbt: the early return is nowend < first_invalid, documented as a deviation, with a backend regression test.Geometry is unchanged by the batching: the same heights are measured in the same frame; only the number of forced layouts drops from one per zone to a constant per pass.
Measurements
Chromium, desktop browser bundle via the e2e harness, time from click to a fully colored viewport:
Before, the first paint itself was blocked until the measurement task finished (967 ms at 20k lines); after, every visible line is colored at the first paint.
Verification
moon check --target js --deny-warnand--target native --deny-warnineditor/and at the rootmoon test --target jsineditor/(3186 tests),moon test --target native viewer/common/modelmoon test --target js desktop/frontend/fileeditor(147 tests)moon fmt --checkin both workspaces;moon infofor the two changed packagesFollow-ups (not in this PR)
Every doc comment is still rendered to DOM and laid out once on open, so the remaining cost is linear in doc-comment content (about 0.3 s at 20k lines). Rendering and measuring only viewport zones would remove that, but it changes the geometry contract that reveal and review navigation rely on.
🤖 Generated with Claude Code
https://claude.ai/code/session_01BGkUVgkpJqT3TQTu2hN5YW