perf(analysis): virtualize the LOG viewer (smooth scroll/select on huge logs)#25
Merged
Conversation
Opening was already fixed (single-insert), but an 80k-line log still kept ~250k DOM nodes, so scrolling and especially drag-selecting text lagged hard (selecting across content-visibility lines forces them all to lay out, which could lock up the renderer). Render only the lines near the viewport: a fixed-height window with top/bottom spacer divs holding the off-screen height; the rest never enter the DOM. The features that assumed every line was in the DOM are routed through the lines array + a windowed anaLineEl(idx): scroll-to-line, current line, bookmarks, find highlights, copy, line click. Markers for the minimap/levels are still scanned across all lines once (~45ms for 82k). content-visibility is removed. The viewer is now always nowrap (long lines scroll horizontally) because virtualization needs a fixed line height, so the word-wrap toggle button and its code/i18n are removed. PgUp/PgDn focus fix: the scroller (#anaScroll), which is never rebuilt, is the keyboard-focus target (tabindex=-1, focused on open and on click), so paging and arrows keep working after the window re-renders. Measured on a real 82,576-line log: opening stays fast and scroll/selection are smooth; selection no longer locks up.
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
After the earlier single-insert fix (#23) opening got fast, but an ~82k-line log still kept ~250k DOM nodes. Scrolling and especially drag-selecting text lagged badly — selecting across
content-visibilitylines forces the browser to lay them all out (it could effectively lock up the renderer).Fix: virtualize the viewer
Render only the lines near the viewport — a fixed-height window with top/bottom spacer divs holding the off-screen height. The rest never enter the DOM, so the node count stays ~constant regardless of file size.
Everything that assumed every line was in the DOM is routed through the lines array + a windowed
anaLineEl(idx):content-visibilityis removed. The viewer is now nowrap (long lines scroll horizontally) because virtualization needs a fixed line height — so the word-wrap toggle button and its code/i18n are removed.Also: PgUp/PgDn focus fix
Paging stopped working after the first press because re-rendering the window destroyed whatever held keyboard focus. Now the scroller (
#anaScroll, which is never rebuilt) is the focus target (tabindex="-1", focused on open and on click), so PgUp/PgDn/Home/End/arrows keep working.Result
On a real 82,576-line log: opening stays fast, scrolling and text selection are smooth, and selection no longer locks up. DOM nodes drop from ~250k to ~a few hundred.
Testing
npm test→ 4/4.Note
Word-wrap is intentionally removed (a fixed line height is required for virtualization); long lines scroll horizontally instead.