Look a refreshed resource up once instead of three times - #2919
Merged
vogella merged 1 commit intoSep 14, 2026
Merged
Conversation
vogella
force-pushed
the
refresh-one-lookup-per-resource
branch
from
September 10, 2026 20:10
fdb893f to
36f1775
Compare
vogella
marked this pull request as ready for review
September 10, 2026 20:10
Contributor
Refreshing walked the element tree from its root three times per directory entry: once to decide membership, once to ask whether the member is a link, and once in the visitor. Container now hands out the infos it collected anyway, and the visitor reads one info per node. A full workspace refresh over 293953 files drops from a median of 2486 ms to 2308 ms, with a fifth fewer garbage collections. Assisted-by: multiple AI agents and layers of automated tooling 🤖
vogella
force-pushed
the
refresh-one-lookup-per-resource
branch
from
September 14, 2026 08:48
36f1775 to
76393a1
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.
Refreshing a resource walked the element tree from its root three times per directory entry:
Container.getChildrenfetched theResourceInfoto decide membership,UnifiedTree.addChildrenthen asked the member itself whether it is a link, andRefreshLocalVisitor.visitasked for the info again. Each walk does a binary search per path segment and allocates aDataTreeLookup, and the single entry lookup cache inElementTreeis keyed on path identity, so the next member evicts the previous one and every walk is a miss.Containernow hands out the infos it collected anyway, and the visitor reads one info per node, which leaves one walk per entry. The one place that still needs a second lookup is aftermakeLocal, because that opens the info for modification and may replace the object.Measured on a workspace with 609 projects and 293953 files, a full refresh that finds nothing to change drops from a median of 2486 ms to 2308 ms over eight runs, and the two ranges do not overlap. Flight recordings over three refreshes each count 1679 garbage collections against 2136, a fifth fewer, with the longest pause unchanged at about 130 ms. This is plain Java with no native code involved, so every platform benefits rather than only the ones whose file system handler has been tuned.