Show a large comparison before computing its differences - #2837
Merged
vogella merged 1 commit intoJul 31, 2026
Conversation
Contributor
TextMergeViewer computed the line diff and the token diffs of every change before the documents were painted, so the editor stayed blank for the whole comparison. Once both sides together exceed 2000 lines the first comparison now runs in a follow-up UI event, the same way the re-diff after an edit already does, and the change highlighting plus the jump to the first difference follow when it is done. Smaller inputs are still compared right away: there the diff costs next to nothing and showing the text and jumping to the first change in two steps would only flicker. A refresh is never deferred either, because it restores the cached selection and scroll position which are dropped as soon as the refresh returns. Measured on Linux with Xvfb, medians over 15 repetitions, time from openCompareEditor until the text is visible: 5000 lines, 100 changes: 237ms -> 77ms 5000 lines, 1250 changes: 491ms -> 96ms 50000 lines, 1000 changes: 427ms -> 135ms Contributes to eclipse-platform#2795
vogella
force-pushed
the
compare-async-initial-diff
branch
from
July 31, 2026 08:11
23b30c8 to
bb67c21
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
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.
TextMergeViewercomputed the line diff and the token diffs of every change before the documents were painted, so opening a compare editor left it blank for the whole comparison. Once both sides together exceed 2000 lines, the first comparison now runs in a follow-up UI event, exactly the way the re-diff after an edit already works, and the change highlighting plus the jump to the first difference follow when it is done. Time fromopenCompareEditoruntil the text is visible, medians over 15 repetitions on Linux with Xvfb: 237ms to 77ms for 5000 lines with 100 changes, 491ms to 96ms for 5000 lines with 1250 changes, and 427ms to 135ms for 50000 lines with 1000 changes.Two cases stay synchronous on purpose. Smaller inputs are compared right away, because there the diff costs next to nothing and showing the text and then jumping to the first change would only flicker; that also keeps the existing contract for the many small comparisons that dominate in practice. A refresh is never deferred either, since it restores the cached selection and scroll position, and that cache is dropped as soon as the refresh returns.
TextMergeViewerTest.testLargeInputIsShownBeforeItIsComparedpins the new behaviour and fails without the change.Contributes to #2795