Refactor: Improve refresh action performance with parallel processing#3576
Refactor: Improve refresh action performance with parallel processing#3576vogella wants to merge 2 commits intoeclipse-platform:masterfrom
Conversation
|
This pull request changes some projects for the first time in this development cycle. 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 patchFurther information are available in Common Build Issues - Missing version increments. |
iloveeclipse
left a comment
There was a problem hiding this comment.
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.
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>
02f095d to
ccda0fc
Compare
|
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>
The WorkspaceJob Javadoc says the opposite : // org.eclipse.core.resources/WorkspaceJob.java (Starting line 47) |
Replaced WorkspaceModifyOperation with IRunnableWithProgress and direct Job usage in RefreshAction and ResourceMgmtActionProvider to enable parallel refreshing of resources and improve performance.