Add a Build Monitor view showing where each build spends its time - #2896
Open
vogella wants to merge 1 commit into
Open
Add a Build Monitor view showing where each build spends its time#2896vogella wants to merge 1 commit into
vogella wants to merge 1 commit into
Conversation
Contributor
vogella
force-pushed
the
build-monitor-view
branch
2 times, most recently
from
September 10, 2026 17:24
f1e568c to
26be815
Compare
vogella
marked this pull request as ready for review
September 10, 2026 19:03
Finding the builder that makes a build slow currently means starting Eclipse with -debug and reading the performance log. This adds an org.eclipse.ui.buildmonitor bundle with a Build Monitor view that records every build and breaks it down, grouped either by project or by builder, with the run count, the time and the share of the build. Tracing is switched on while the view is open and the previous debug options are restored when it closes, so no restart is needed. Each build is bracketed by PRE_BUILD and POST_BUILD and the per builder counters of PerformanceStats are diffed between the two. Those counters are updated while the builder returns, unlike the listener callbacks, which PerformanceStatsProcessor batches with a two second delay and which therefore cannot be attributed to the build that caused them. The build row also carries the wall clock time of the whole build, so the part that is not spent inside builders is visible. Assisted-by: multiple AI agents and layers of automated tooling 🤖
vogella
force-pushed
the
build-monitor-view
branch
from
September 10, 2026 20:16
26be815 to
4a80ebd
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
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.
Finding the builder that makes a build slow currently means starting Eclipse with
-debugand reading the performance log. This adds anorg.eclipse.ui.buildmonitorbundle with a Build Monitor view that records every build and lets you drill from the build into its projects and then into the builders that ran on them, or the other way round with the "By builder" switch. Each row shows the run count, the time and its share of the build, and the build row also shows the wall clock time, so the part of a build that is not spent inside builders is visible at a glance. Tracing is switched on while the view is open and the previous debug options are restored when it closes, so no restart is needed and nothing is written to the performance log.The interesting part is how the time is attributed.
PerformanceStatsProcessorbatches its listener callbacks with a two second delay, so events for a short build arrive after it has finished and cannot be assigned to it. Instead each build is bracketed byPRE_BUILDandPOST_BUILDand the per builder counters ofPerformanceStatsare diffed between the two; those counters are updated synchronously while the builder returns, so the numbers are exact and the view refreshes once per build rather than once per builder run.The bundle is not yet listed in the platform feature, that needs a follow-up in eclipse.platform.releng.aggregator before it ships in the SDK. The runtime switchable tracing it depends on landed with #2802.