Community
Participate
Working Groups
I20090114-1322 My gut feeling tells me that the delay before runtime workbenches are launched has become bigger in 3.5 (and I've also been asked by others about that). Today, I took the attached CPU trace (sampling) and saw that most of the time between hitting the Debug button and the actual launch starts is burned in org.eclipse.core.internal.events.BuildManager.needsBuild(..), which calls org.eclipse.core.internal.dtree.DeltaDataTree.forwardDeltaWith(..).
Created attachment 122697 [details] CPU trace (sampling)
Do you have autobuild on or off? Is this after a large number of changes? I don't see any time for the actual build here, which means the build itself took 0ms, or the sampling was stopped before the build started...
The workspace is completely built before the launch. Auto-build is enabled. My steps were: - wait until Progress view is empty - start sampling - click the Debug button - stop sampling when the target VM shows up in the Debug view Indeed, no builder was running, but BuildManager.needsBuild(..) needed almost 9s to find this out (repeatably, so it is unlikely a GC or page fault problem). I'm not sure if that's important here, but my Local History settings are still in "keep everything" mode (bug 257167 comment 3).
ping
I do see some interesting things happening here. The build is heavily optimized for incremental workspace build, which I suspect in your workspace is still very fast (to test this try touching a text file in a generic project with autobuild on and see how long build takes). This is done by caching deltas within the build manager to avoid recomputing them. However, it turns out launch does not invoke a workspace build anymore. What it does now is invoke IProject#build on each project in the workspace (presumably each project related to the thing being launched). In my workspace this amounts to 140 invocations of IProject#build. Thus the delta computation is 140x slower because each build creates new tree layers, so a fresh delta needs to be calculated. We might be able to optimize for this in the build manager. If you want to see how long these delta calculations are taking in your workspace, there are option flags for showing this: org.eclipse.core.resources/debug=true org.eclipse.core.resources/build/needbuild=true I'm seeing 15-30ms per build, which can add up to 4+ seconds in my 140 project workspace.
Correct - debug performs a build scoped to the projects relevant to the launch, rather than all projects in the workspace.
> debug performs a build scoped to the projects relevant to the launch Why do you do this given that auto-build on? Shouldn't it simply wait until eventually pending incremental builds are done?
> Why do you do this given that auto-build on? Shouldn't it simply wait until > eventually pending incremental builds are done? Many kinds of builders don't respond at all to autobuild (for example Ant builders and CDT builders). So I can see why an incremental build is needed here. Darin, I think minimally you should be wrapping all these calls in an IWorkspaceRunnable. Currently there is a top-level operation for each project, which means separate resource change events, etc, for each project. If you could run the entire build in an IWorkspaceRunnable, we may be able to optimize this in the build manager.
(In reply to comment #7) > > debug performs a build scoped to the projects relevant to the launch > Why do you do this given that auto-build on? Shouldn't it simply wait until > eventually pending incremental builds are done? If a build is in progress while launching, we wait for the build to complete (there is a preference setting to control this as well). If auto build is on, we still build before launching (based on user preference setting) - this is because there is no API to tell if the workspace state is "completely built". For example, a user may have canceled the last build in progress, leaving the build state incomplete. (In reply to comment #8) > Darin, I think minimally you should be wrapping all these calls in an > IWorkspaceRunnable. Currently there is a top-level operation for each project, > which means separate resource change events, etc, for each project. If you > could run the entire build in an IWorkspaceRunnable, we may be able to optimize > this in the build manager. OK, I will open defect against debug for this.
Investigating.
Created attachment 132620 [details] Fix This is a targetted optimization for the case where autobuild is on, the client is invoking incremental build, and all builders on a given project respond to auto-build. A build should not be needed in this case.
Created attachment 132621 [details] Performance test
The performance test runs 20 builds on each project, in a workspace containing 100 projects with 5 builders per project, and 100 resources per project. The attached optimization takes the test from 10 seconds, down to 200 milliseconds.
This fix has been released to HEAD.
We need to revert this fix because it caused a breaking change for clients. See bug 275879 for details. We'll have to revisit in a future release to see if we can come up with a safer optimization.
This was addressed by the fix in bug 276319. *** This bug has been marked as a duplicate of bug 276319 ***
