Read the compared contents once, in the background - #2840
Merged
vogella merged 1 commit intoAug 3, 2026
Conversation
Contributor
vogella
force-pushed
the
compare-prefetch-contents
branch
2 times, most recently
from
July 31, 2026 14:34
c8e3000 to
fee6afc
Compare
vogella
marked this pull request as ready for review
July 31, 2026 14:34
vogella
force-pushed
the
compare-prefetch-contents
branch
from
August 2, 2026 18:16
fee6afc to
3ec0c54
Compare
Opening a compare editor read each side three times: once for content type detection, once for the text heuristic and once for the document shown in the viewer, all three on the UI thread and each one paying whatever the provider charges for opening a stream. For an EGit revision that means inflating the blob and running the smudge filters three times over. The background job that prepares the input now reads the contents once and the sniffing and the merge viewer are served from that. Elements backed by a shared document are skipped, since those come from the file buffer and never read a stream anyway. Only contents that look like text are kept, and only up to 8 MB of them. The binary viewer stops at the first differing byte, so reading a binary in full ahead of it would be slower than not prefetching at all, and the text merge viewer never sees it. Deciding that costs an 8 KB probe. What is kept is held weakly and dropped as soon as it became a document, so it goes away with the editor that prepared it even when no viewer asks for it. The read checks the monitor, so cancelling stays responsive on exactly the slow providers this targets. CompareOpenEfficiencyTest's bound drops from 3 reads per side to 1, and a new test pins the binary side to a bounded number of bytes. Contributes to eclipse-platform#2795
vogella
force-pushed
the
compare-prefetch-contents
branch
from
August 2, 2026 18:36
3ec0c54 to
c1ff1d1
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.
Opening a compare editor read each side three times: once for content type detection, once for the text heuristic and once for the document shown in the viewer. All three happened on the UI thread and each one paid whatever the provider charges for producing a stream; for an EGit revision that means inflating the blob and running the smudge and EOL filters three times over.
The background job that prepares the input now reads the contents once, and both the sniffing and the merge viewer are served from that. Elements backed by a shared document are skipped, since those are served from the file buffer and never read a stream anyway, which is exactly the local side of a typical comparison. An entry is dropped as soon as it became a document, so at most one input's contents are held at a time.
CompareOpenEfficiencyTest's bound drops from 3 reads per side to 1, and I verified that the bound really depends on the prefetch: with the prefetch call removed the test reports 3 again.Contributes to #2795