Keep marker attribute access off the UI thread in the markers view - #4304
Keep marker attribute access off the UI thread in the markers view#4304vogella wants to merge 1 commit into
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. |
There was a problem hiding this comment.
Pull request overview
Moves marker counting off the UI thread and reduces repeated sorting and formatting allocations.
Changes:
- Cache severity counts in background updates and clones.
- Reuse collation keys and a shared
Collator. - Reuse the parsed summary message format.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
Markers.java |
Computes and clones cached marker counts. |
MarkerEntry.java |
Adds shared collation and prior-generation caching. |
ExtendedMarkersView.java |
Reuses a parsed summary formatter. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
11759c7 to
d933591
Compare
Profiling a rebuild showed three avoidable costs. The severity counts for the title were computed on the UI thread by calling IMarker.getAttribute for every entry again, throwing a ResourceException for each marker deleted since the gather; they are now computed on the update job and carried into the clone. Collation keys for sorting were recomputed after every update with a fresh Collator per miss; one Collator is shared and the previous update's keys are kept for one round. The summary message pattern was re-parsed by MessageFormat on every title update; it is now parsed once. Assisted-by: multiple AI agents and layers of automated tooling 🤖
d933591 to
32528c3
Compare
…thread in the markers view
Upstream master plus these PRs: eclipse.jdt.core -> https://github.com/vogella/eclipse.jdt.core.git vogella-master @ a4eb5e4ef8 (eclipse-jdt/eclipse.jdt.core#5309) eclipse.platform.ui -> https://github.com/vogella/eclipse.platform.ui.git vogella-master @ 51e813eec6 (eclipse-platform/eclipse.platform.ui#4260 eclipse-platform/eclipse.platform.ui#4304 eclipse-platform/eclipse.platform.ui#4305 eclipse-platform/eclipse.platform.ui#4326 eclipse-platform/eclipse.platform.ui#4327) eclipse.jdt.ui -> https://github.com/vogella/eclipse.jdt.ui.git vogella-master @ 2073494827 (eclipse-jdt/eclipse.jdt.ui#3142 eclipse-jdt/eclipse.jdt.ui#3131 eclipse-jdt/eclipse.jdt.ui#3127 eclipse-jdt/eclipse.jdt.ui#3058) eclipse.pde -> https://github.com/vogella/eclipse.pde.git vogella-master @ 55877fce19 (eclipse-pde/eclipse.pde#2463 eclipse-pde/eclipse.pde#2444 eclipse-pde/eclipse.pde#2443)
Profiling a Problems view rebuild (3350 markers, full build of
org.eclipse.jfaceas the marker churn, in-IDE sampler plus JFR) showed three avoidable costs. The severity counts for the view title were computed on the UI thread by callingIMarker.getAttributeagain for every entry, which throws aResourceExceptionfor each marker deleted since the gather; they are now computed on the update job and carried into the clone. Collation keys for sorting were recomputed after every update with a freshCollatorper cache miss; oneCollatoris shared and the previous update's keys are kept for one round. The summary message pattern was re-parsed byMessageFormaton every title update and is now parsed once.Measured before and after with the same workload, from the two JFR recordings:
views.markerscodeResourceExceptionplus wrappedIllegalStateExceptionfromMarkers.getMarkerCountson the UI thread,IllegalArgumentExceptioninsideMessageFormat)UIUpdateJob.runInUIThreadMarkerEntry.getCollationKeyMarkerUpdateJob.runThe last row is not a like-for-like speedup: the dependent auto-build ran 53 s in the baseline and 17 s in the second run, so fewer marker updates happened. The exception and collation rows are per-update effects and hold regardless. The markers view is a small share of a rebuild overall; the point of the change is that the UI thread no longer touches marker attributes or throws for stale markers during builds.