Skip to content

Refactor: Improve refresh action performance with parallel processing#3576

Draft
vogella wants to merge 2 commits intoeclipse-platform:masterfrom
vogella:parallel-refresh
Draft

Refactor: Improve refresh action performance with parallel processing#3576
vogella wants to merge 2 commits intoeclipse-platform:masterfrom
vogella:parallel-refresh

Conversation

@vogella
Copy link
Contributor

@vogella vogella commented Dec 12, 2025

Replaced WorkspaceModifyOperation with IRunnableWithProgress and direct Job usage in RefreshAction and ResourceMgmtActionProvider to enable parallel refreshing of resources and improve performance.

@vogella vogella marked this pull request as draft December 12, 2025 08:45
@eclipse-platform-bot
Copy link
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.ide/META-INF/MANIFEST.MF
bundles/org.eclipse.ui.navigator.resources/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 f5f3e057eccd27caeb7f5fe89182333edc941027 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Fri, 12 Dec 2025 08:56:11 +0000
Subject: [PATCH] Version bump(s) for 4.39 stream


diff --git a/bundles/org.eclipse.ui.ide/META-INF/MANIFEST.MF b/bundles/org.eclipse.ui.ide/META-INF/MANIFEST.MF
index c115a47b5f..0d2916a41c 100644
--- a/bundles/org.eclipse.ui.ide/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.ui.ide/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Plugin.name
 Bundle-SymbolicName: org.eclipse.ui.ide; singleton:=true
-Bundle-Version: 3.22.800.qualifier
+Bundle-Version: 3.22.900.qualifier
 Bundle-Activator: org.eclipse.ui.internal.ide.IDEWorkbenchPlugin
 Bundle-ActivationPolicy: lazy
 Bundle-Vendor: %Plugin.providerName
diff --git a/bundles/org.eclipse.ui.navigator.resources/META-INF/MANIFEST.MF b/bundles/org.eclipse.ui.navigator.resources/META-INF/MANIFEST.MF
index 484bfaa8e9..c43a4b1f3a 100644
--- a/bundles/org.eclipse.ui.navigator.resources/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.ui.navigator.resources/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.resources; singleton:=true
-Bundle-Version: 3.9.900.qualifier
+Bundle-Version: 3.9.1000.qualifier
 Bundle-Activator: org.eclipse.ui.internal.navigator.resources.plugin.WorkbenchNavigatorPlugin
 Bundle-Vendor: %Plugin.providerName
 Bundle-Localization: plugin
-- 
2.52.0

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

@github-actions
Copy link
Contributor

github-actions bot commented Dec 12, 2025

Test Results

 3 024 files  ±0   3 024 suites  ±0   2h 10m 23s ⏱️ - 6m 21s
 8 234 tests ±0   7 986 ✅ ±0  248 💤 ±0  0 ❌ ±0 
23 526 runs  ±0  22 735 ✅ ±0  791 💤 ±0  0 ❌ ±0 

Results for commit 1153544. ± Comparison against base commit 89a19bf.

♻️ This comment has been updated with latest results.

Copy link
Member

@iloveeclipse iloveeclipse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original code was executed as WorkspaceModifyOperation with a rule, not it seem that you explicitly allows multiple threads to run multiple workspace related tasks without holding any rule.

Even as a draft, this makes no sense.

@merks
Copy link
Contributor

merks commented Dec 12, 2025

Even as a draft, this makes no sense.

I was about to post the same comment for the same reason.

Previously a single WorkspaceJob was scheduled with a combined
MultiRule across all selected projects. This still refreshed all
resources sequentially and held every project lock simultaneously,
which was more restrictive than needed.

Now RefreshAction.run() groups resources by their scheduling rule
(project or workspace root) and calls scheduleRefreshJob() once per
group. Each group gets its own WorkspaceModifyOperation protected by
only that project's rule, so independent projects can be refreshed
in parallel while concurrent workspace access to a single project
is still prevented.

Two new protected hook methods are added to RefreshAction:
- createRefreshJob(): builds the WorkspaceModifyOperation-wrapped
  WorkspaceJob without scheduling it, so callers can attach
  IJobChangeListeners before scheduling (no race condition).
- scheduleRefreshJob(): default implementation calls
  createRefreshJob().schedule(); subclasses override to customise.

ResourceMgmtActionProvider no longer duplicates the run() logic.
It overrides scheduleRefreshJob() instead, attaches a JobChangeAdapter
that triggers a Navigator viewer refresh after each project's job
completes, then schedules the job.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@iloveeclipse
Copy link
Member

Workspace operations in general can't be parallelized, there is always a central workspace lock anyway.

When multiple projects are refreshed simultaneously, the Progress view
previously showed identical "refresh" entries for every job. Each job
now uses "refresh (ProjectName)" so users can see which project is
being refreshed. Jobs covering the workspace root retain the plain
"refresh" title.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@vogella
Copy link
Contributor Author

vogella commented Feb 20, 2026

Workspace operations in general can't be parallelized, there is always a central workspace lock anyway.

The WorkspaceJob Javadoc says the opposite :

// org.eclipse.core.resources/WorkspaceJob.java (Starting line 47)


 * Note that the workspace is not locked against other threads during the execution
 * of a workspace job. Other threads can be modifying the workspace concurrently
 * with a workspace job.  To obtain exclusive access to a portion of the workspace,
 * set the scheduling rule on the job to be a resource scheduling rule.  The
 * interface {@link IResourceRuleFactory} is used to create a  scheduling rule
 * for a particular workspace modification operation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

Comments