Skip to content

Avoid the full ancestor chain walk when removing elements from the Project Explorer - #4260

Open
vogella wants to merge 2 commits into
eclipse-platform:masterfrom
vogella:navigator-parent-lookup
Open

Avoid the full ancestor chain walk when removing elements from the Project Explorer#4260
vogella wants to merge 2 commits into
eclipse-platform:masterfrom
vogella:navigator-parent-lookup

Conversation

@vogella

@vogella vogella commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Deleting many files below a collapsed folder freezes the Project Explorer. AbstractTreeViewer.getParentElement prefers ITreePathContentProvider, so the Common Navigator answers through getParents, which compiles complete paths up to the root although only the last segment of the first path is ever used. AbstractTreeViewer.internalRemove takes that branch for every element without a widget, and with JDT enabled each ancestor level runs JavaCore.create against the workspace tree. Measured in a running IDE, deleting 2000 files ten folders deep froze the UI for 19 s; with this change the same removal is not measurable and no freeze is logged.

CommonViewer now asks getParent first and falls back to the inherited behaviour when it returns null, which confines the change to the Common Navigator. For that to be correct, getParent had to honour pipelined overrides: it resolved overriding extensions up front and called the override's plain getParent, so getPipelinedParent never ran and the pipelining code in getParent was unreachable. It now reuses findParents, the per-level routine getParents already uses, so both lookups agree. Two tests pin this: one that the override's getPipelinedParent is consulted, one that removing an unexpanded element computes exactly one parent.

@github-actions

github-actions Bot commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Test Results

   858 files  ±0     858 suites  ±0   45m 58s ⏱️ - 12m 15s
 8 218 tests +2   7 975 ✅ +2  243 💤 ±0  0 ❌ ±0 
20 556 runs  +6  19 886 ✅ +6  670 💤 ±0  0 ❌ ±0 

Results for commit 14e9435. ± Comparison against base commit a680fa8.

♻️ This comment has been updated with latest results.

@vogella
vogella force-pushed the navigator-parent-lookup branch from 6034db8 to d93adab Compare August 31, 2026 12:09
@vogella vogella added plan Planned bugs/enhancements for a release and removed Planned for 4.42 labels Aug 31, 2026
@eclipse-platform-bot

Copy link
Copy Markdown
Contributor

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

bundles/org.eclipse.ui.navigator/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch
From 502eb818d56ad93e2c65144528ad9250920c1561 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Mon, 31 Aug 2026 12:14:12 +0000
Subject: [PATCH] Version bump(s) for 4.42 stream


diff --git a/bundles/org.eclipse.ui.navigator/META-INF/MANIFEST.MF b/bundles/org.eclipse.ui.navigator/META-INF/MANIFEST.MF
index 1663ec6e36..0036dd7e70 100644
--- a/bundles/org.eclipse.ui.navigator/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.ui.navigator/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Plugin.name
 Bundle-SymbolicName: org.eclipse.ui.navigator; singleton:=true
-Bundle-Version: 3.14.200.qualifier
+Bundle-Version: 3.14.300.qualifier
 Bundle-Activator: org.eclipse.ui.internal.navigator.NavigatorPlugin
 Bundle-Vendor: %Plugin.providerName
 Bundle-Localization: plugin
-- 
2.55.0

Further information are available in Common Build Issues - Missing version increments.

@vogella
vogella force-pushed the navigator-parent-lookup branch 2 times, most recently from f78b390 to 61c2e4d Compare September 1, 2026 08:02
…getParent

getParent() resolved overriding extensions up front, so for an element
covered by an overriding extension it called that extension's plain
getParent() and never consulted the overridden extension or the
override's getPipelinedParent(). getParents() takes the other route:
it asks the overridden extension and pipes the result through the
overriding extensions, which is what IPipelinedTreeContentProvider
promises. The pipelining code in getParent() was unreachable for the
same reason, and it also handed the Object[] holder to pipelineParent()
instead of the parent it held.

Compute the parent with findParents(), which getParents() already uses
for each level, and drop pipelineParent().

Assisted-by: multiple AI agents and layers of automated tooling 🤖
AbstractTreeViewer.getParentElement() prefers ITreePathContentProvider,
so for the Common Navigator it calls getParents(), which compiles
complete paths up to the root. Only the last segment of the first path
is used, so every ancestor level above the immediate parent is computed
and discarded, and each level asks every enabled content extension for a
parent. With JDT enabled that runs JavaCore.create and hasJavaNature per
level, which hit the workspace tree.

AbstractTreeViewer.internalRemove() takes this branch for elements that
have no widget, so deleting many never expanded files paid the full walk
per element and froze the UI. Override getParentElement() to ask
getParent() first and fall back to the inherited behaviour when it
returns null.

Assisted-by: multiple AI agents and layers of automated tooling 🤖
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

plan Planned bugs/enhancements for a release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants