Community
Participate
Working Groups
I have a workspace with 197 projects. Approximately 20 are from a CVS repository. I have CVS label decorations turned on. When I close or open a project, the workspace is busy for an very long time.
Does performance improve if you turn off CVS label decorations?
Do you have autobuild on? Are there prerequisite relationships between the projects (i.e. does the closed project have dependents that need to be rebuilt)?
Autobuild is off; no difference in performance with label decorations turned off. I am using the RC1 build.
What does the progress monitor report when waiting?
The monitor says "updating.". Others on the team have observed the same thing after adding a project from CVS.
What perspective are you in? Do you have multiple perspectives open? If you open just a resource perspective (with no other windows or perspectives open), close all editors, and try again, is it any better? I suspect certain views are taking a long time processing workbench deltas.
I had a Java perspective, CVS perspective, and debug perspective open. I just closed them all and left only the Resource perspective with the navigator, and closed the project. Same problem.
Is this fixed for 2.1? I'm still seeing it in the 0326 integration build.
Although various performance improvements were made for 2.1, this particular bug was not addressed for 2.1 (which is why it's still open).
I see the same pause when creating a new Java project in our self-hosting environment. We certainly have lots of dependencies within the 300 plug-in projects I have loaded, but I don't think any of them are truly cyclical, and none of them are showing build-path errors. Here is the state of the VM during the pause, from a ctrl-break on the 2.1 build: Full thread dump Classic VM (J2RE 1.3.1 IBM Windows 32 build cn131-20020710, native threads): "Snapshot" (TID:0x190BDE0, sys_thread_t:0x1382D248, state:CW, native ID:0x454) prio=5 at java.lang.Object.wait(Native Method) at org.eclipse.core.internal.resources.DelayedSnapshotRunnable.run (DelayedSnapshotRunnable.java:38) at java.lang.Thread.run(Thread.java:512) "Decoration" (TID:0x254B2B8, sys_thread_t:0x12EC6800, state:CW, native ID:0x8F8) prio=1 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:429) at org.eclipse.ui.internal.decorators.DecorationScheduler.next (DecorationScheduler.java:214) at org.eclipse.ui.internal.decorators.DecorationScheduler$2.run (DecorationScheduler.java:240) at java.lang.Thread.run(Thread.java:512) "org.eclipse.jdt.internal.ui.text.JavaReconciler" (TID:0x26C9160, sys_thread_t:0x12EBCD88, state:CW, native ID:0x884) prio=1 at java.lang.Object.wait(Native Method) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run (AbstractReconciler.java:161) "Java indexing" (TID:0x900270, sys_thread_t:0x128A8218, state:CW, native ID:0x684) prio=4 at java.lang.Thread.sleep(Native Method) at org.eclipse.jdt.internal.core.search.processing.JobManager.run (JobManager.java:349) at java.lang.Thread.run(Thread.java:512) "Finalizer" (TID:0x901900, sys_thread_t:0x891750, state:CW, native ID:0x144) prio=8 at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java(Compiled Code)) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java(Compiled Code)) "Reference Handler" (TID:0x901948, sys_thread_t:0x882578, state:CW, native ID:0x5D4) prio=10 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java(Compiled Code)) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java(Compiled Code)) "Signal dispatcher" (TID:0x901990, sys_thread_t:0x87F598, state:R, native ID:0x8A4) prio=5 "main" (TID:0x9019D8, sys_thread_t:0x7B0A58, state:R, native ID:0x794) prio=5 at org.eclipse.jdt.internal.core.DeltaProcessor.updateClasspathMarkers (DeltaProcessor.java:1956) at org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged (DeltaProcessor.java:1693) at org.eclipse.core.internal.events.NotificationManager$1.run (NotificationManager.java:137) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java(Compiled Code)) at org.eclipse.core.runtime.Platform.run(Platform.java(Compiled Code)) at org.eclipse.core.internal.events.NotificationManager.notify (NotificationManager.java:152) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges (NotificationManager.java:67) at org.eclipse.core.internal.resources.Workspace.broadcastChanges (Workspace.java:161) at org.eclipse.core.internal.resources.Workspace.endOperation (Workspace.java(Compiled Code)) at org.eclipse.core.internal.resources.Workspace.run (Workspace.java:1600) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:2711) at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run (WorkbenchRunnableAdapter.java:42) at org.eclipse.jface.operation.ModalContext.runInCurrentThread (ModalContext.java:302) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:252) at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:758) at org.eclipse.jdt.internal.ui.wizards.NewElementWizard.performFinish (NewElementWizard.java:96) at org.eclipse.jface.wizard.WizardDialog.finishPressed (WizardDialog.java:608) at org.eclipse.jface.wizard.WizardDialog.buttonPressed (WizardDialog.java:321) at org.eclipse.jface.dialogs.Dialog$1.widgetSelected(Dialog.java:423) at org.eclipse.swt.widgets.TypedListener.handleEvent (TypedListener.java:89) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java (Compiled Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java (Compiled Code)) at org.eclipse.jface.window.Window.runEventLoop(Window.java(Compiled Code)) at org.eclipse.jface.window.Window.open(Window.java:563) at org.eclipse.ui.actions.NewWizardAction.run(NewWizardAction.java:136) at org.eclipse.ui.internal.NewWizardDropDownAction.run (NewWizardDropDownAction.java:96) at org.eclipse.jface.action.Action.runWithEvent(Action.java:842) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:456) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent (ActionContributionItem.java:403) at org.eclipse.jface.action.ActionContributionItem.access$0 (ActionContributionItem.java:397) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent (ActionContributionItem.java:72) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java (Compiled Code)) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java(Compiled Code)) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java (Compiled Code)) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java (Compiled Code)) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java (Compiled Code)) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1385) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:845) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:291) at org.eclipse.core.launcher.Main.run(Main.java:747) at org.eclipse.core.launcher.Main.main(Main.java:583)
The stack trace is interesting, but it only gives us one data point. When you say the workspace is busy for a long time, how long is long? If you dump the stack multiple times during this period, does it always look the same? Would you be able to try installing the Core Tools (v1.0.0) at the following URL and check out what's shown in the Builders/Listeners Spy view? http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core- home/dev.html#tools This will show the activity of all builders and workspace listeners, and the time taken by them. See the readme there for installation instructions. After copying the .options file from eclipse/plugins/org.eclipse.core.resources to eclipse/, edit it to specify: org.eclipse.core.resources/monitor/builders=true org.eclipse.core.resources/monitor/listeners=true Thanks.
As we discussed recently, there are a few approaches to solve this: 1) Add exclusion filters which would allow us to replace the Java build path page with our own, based on the nature. There are some limitations to this. -A. We don't want to copy all the code in the Java build path page and reference internal code. There is some function in Java build path that we still want to keep, e.g., source folders, classes folders, libraries. -B. We actually have 3 different property pages that can modify the build path 2) Change the build path page to use a notification based working copy of the Java build path. The all our pages can use this as well. When the working copy is changed, the property pages can refresh accordingly. 3) Change the behavior of preferences such that changing the page will apply the changes. Then all build path related pages need to refresh when they are re-focused. Pages that force an autobuild would indicate this but the autobuild would not fire until the dialog is closed. This issue is very important to our product, and we'd like to see some resolution in the 3.0 timeframe.
Ritchie, I was not privy to the recent discussions you refer to. Also, the points above about the build path page seems unrelated to the topic of this PR (performance of open/close project). Or am I missing something?
Sorry, please disregard the last remark; it was a bugzilla blunder. Wrong defect (should've been 32378).
I should mention that I have just moved the open/close project actions to run as background jobs. This might help your particular performance scenario, although in this case it looks like classpath computation is taking the time, rather than the actual open/close itself. There was work on improving classpath computation performance in 3.0 so this might no longer be an issue.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
Given that the time seems to be in classpath computation, does this PR still belong in UI?
John, what's your take on this one?
Given that: - The information in this bug is two years old - It's based on 2.1, and the world has significantly changed since then - I can't reproduce any exceptional slowness opening and closing projects in current builds. - We only have one stack trace as a data point, and requests for more details were not answered. I suggest marking as INVALID or WORKSFORME.
How about FIXED? It was valid at the time it was opened :-).
Ritchie, do you still have a similar workspace and are you using the latest 3.1? If so, can you confirm that it's no longer a problem in your workspace?
I haven't seen this in quite some time. I haven't updated to 3.1 yet.
Closing as WORKSFORME then.
