Community
Participate
Working Groups
In the launch configuration dialog, opening a runtime workbench configuration or a junit plug-in test configuration, there is a significant pause (5 seconds or more). This makes even small changes to a configuration an annoying experience.
I'll look at this sometime, but probably not in 3.4.
I would start here first as a possible bottleneck: org.eclipse.pde.internal.ui.launcher.LaunchPluginValidator.parsePlugins(ILaunchConfiguration, String)
Created attachment 97843 [details] Call Tree One place we might be able to make some improvements is PluginBlock.initializeFrom(ILaunchConfiguration, boolean). As it's spending a long time building a table that's not even enabled.
*** Bug 234116 has been marked as a duplicate of this bug. ***
Note that the performance of the launch configuration validation affects more than just the opening of the configuration. Typing in the name field can be slowed down by the work the config is doing when handling events.
Created attachment 104387 [details] Work In Progress
*** Bug 240712 has been marked as a duplicate of this bug. ***
I find that slowness is caused by a different call tree. Loading up a PDE launch configuration sometimes takes up to a minute on my 2.1Mhz Core2 laptop, during this time the UI is frozen and unresponsive. Running jstack on the Eclipse process yields this stack trace. This slowness only seems to occur when the "trace options" checkbox is used. This is really a very annoying problem. Could the "isTraceable" call be deferred until you actually switch to the tracing tab? And once you are there, could it be done to run in a non-UI thread so the UI remains responsive? "main" prio=6 tid=0x003a5c00 nid=0xc1c runnable [0x003fe000..0x003ffe5c] java.lang.Thread.State: RUNNABLE at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at org.eclipse.pde.internal.core.TracingOptionsManager.isTraceable(TracingOptionsManager.java:113) at org.eclipse.pde.internal.ui.launcher.TracingBlock.getTraceableModels(TracingBlock.java:293) at org.eclipse.pde.internal.ui.launcher.TracingBlock.createPluginViewer(TracingBlock.java:108) at org.eclipse.pde.internal.ui.launcher.TracingBlock.createSashSection(TracingBlock.java:75) at org.eclipse.pde.internal.ui.launcher.TracingBlock.createControl(TracingBlock.java:68) at org.eclipse.pde.ui.launcher.TracingTab.createControl(TracingTab.java:56) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationTabGroupViewer.showInstanceTabsFor(LaunchConfigurationTabGroupViewer.java:835) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationTabGroupViewer.displayInstanceTabs(LaunchConfigurationTabGroupViewer.java:771) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationTabGroupViewer$8.run(LaunchConfigurationTabGroupViewer.java:663) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationTabGroupViewer.inputChanged(LaunchConfigurationTabGroupViewer.java:680) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationTabGroupViewer.setInput0(LaunchConfigurationTabGroupViewer.java:642) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationTabGroupViewer.setInput(LaunchConfigurationTabGroupViewer.java:618) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationsDialog.handleLaunchConfigurationSelectionChanged(LaunchConfigurationsDialog.java:959) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationsDialog$4.selectionChanged(LaunchConfigurationsDialog.java:566) at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:842) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:880) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:48) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175) at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:840) at org.eclipse.jface.viewers.StructuredViewer.setSelection(StructuredViewer.java:1639) at org.eclipse.jface.viewers.TreeViewer.setSelection(TreeViewer.java:1104) at org.eclipse.jface.viewers.Viewer.setSelection(Viewer.java:392) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationsDialog.doInitialTreeSelection(LaunchConfigurationsDialog.java:606) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationsDialog.initializeContent(LaunchConfigurationsDialog.java:1061) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationsDialog.createContents(LaunchConfigurationsDialog.java:442) at org.eclipse.jface.window.Window.create(Window.java:431) at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1089) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationsDialog.create(LaunchConfigurationsDialog.java:371) at org.eclipse.jface.window.Window.open(Window.java:790) at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationsDialog.open(LaunchConfigurationsDialog.java:1113) at org.eclipse.debug.ui.DebugUITools$1.run(DebugUITools.java:388) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.debug.ui.DebugUITools.openLaunchConfigurationDialogOnGroup(DebugUITools.java:396) at org.eclipse.debug.ui.DebugUITools.openLaunchConfigurationDialogOnGroup(DebugUITools.java:332) at org.eclipse.debug.ui.actions.OpenLaunchDialogAction.run(OpenLaunchDialogAction.java:81)
*** Bug 244513 has been marked as a duplicate of this bug. ***
I think we can do a better job of caching this information and delaying the actual call to read the .options files. The problem at hand is that we are going through each plug-in in the target platform and reading the .options settings... this is expensive :)
*** Bug 246488 has been marked as a duplicate of this bug. ***
*** Bug 247507 has been marked as a duplicate of this bug. ***
I did some optimizations around how we load the .options files with bug 248152. This should help most people significantly with the performance issues they saw with the dialog. Those changes will go into 3.5M3 and possibly 3.4.2 I will leave this open for further explorations and optimizations that Curtis was attempting.
*** Bug 263774 has been marked as a duplicate of this bug. ***
Created attachment 125535 [details] Yourkit CPU snapshot
Created attachment 125536 [details] Yourkit CPU profiling HTML export
My remark in comment #8 no longer applies. The changes for bug 248152 seemed to make a difference. Now, the bottleneck is the "plugins" tab. The root cause of this is that the implementation of FilteredCheckboxTree is very inefficient. I tried to fix it, but I was not able to in the time I allotted myself. [details... if interested] I thought simply causing the auto-expand level of the tree to be 0 will solve the problem, however the checkbox state of the plugins causes eager loading of all items in the tree. This might be a canidate for the "deffered tree expansion" where children nodes are expanded on a background thread.[end details] Therefore, I went with original approach I mentioned in comment #8 - to defer the loading of that tab until it was actually visible. I was able to create a patch that *deffers* the loading of the plugins tab until the tab is *activated* instead of during the intializeFrom() method. Some initialization still occurs in the intilizeFrom() method (so that validation messages are still intact.) but the population of the FilteredCheckboxTree only happens when you switch to this tab. Switching to the plugins tab still incurs the very slow performance, however, ordinary usage of launch configurations is very snappy now.
Created attachment 125580 [details] Launch config patch
Created attachment 125581 [details] Other patch This one reduces the number of calls to the preferences service when sorting.
Cool, thanks for the patches. I'll review them out and put them in for M6. I was thinking that we should try and go one step further and delay the tree from initializing until it becomes editable. It is silly for us to be taking that much of a performance hit just to populate a disabled tree.
>I was thinking that we should try and go one step further and delay the tree from >initializing until it becomes editable. Definitely. Loading stuff lazy is a key concept in eclipse.
Moving to M7.
Created attachment 129149 [details] Lazy loading of the tree With this patch the tree does not get an input unless the drop down is set to "selected plug-ins only". Patch doesn't appear to break anything and it improved performance if you are not using the tree to select certain plug-ins to launch. I will do some more performance testing to see what else we can improve. This patch also includes Min's changes to ListUtils. I didn't include the 'activate tab' patch because it required debug to change the behaviour of the Launch configuration dialog and I had problems when multiple instances of the same config were open.
I applied Min's "Other patch" and committed a fix to not fill in the table unless the user has chosen "plug-ins selected below only". Without the table filling in the performance of the tab is roughly equivalent to the main tab or any of the other tabs. Min is correct in that the FilteredCheckboxTree is a huge waste of CPU. I was considering using it elsewhere in PDE and now will try and avoid it. Working with the code in PluginBlock is a huge time sink, but if someone would like to take a shot at it go for it. Since the main problem, the LCD taking forever to open, should be fixed in the most common case, I am marking this as FIXED. Chris A, can you test out the dialog and verify?
looks good. I would love to have an optimized FilteredCheckboxTree ;)
(In reply to comment #25) > I would love to have an optimized FilteredCheckboxTree ;) We have some experimental code for this attached to bug 237359. All we need is someone to push it through.
I installed 3.5 and I find the Run Configurations dialog is still incredibly slow, to open and to type text in fields. IMO this bug should be reopened.
(In reply to comment #27) > I installed 3.5 and I find the Run Configurations dialog is still incredibly > slow, to open and to type text in fields. IMO this bug should be reopened. > I see significant improvement in 3.5. I'm using a workspace that was created in 3.4, has a large RCP product (many plug-ins), uses a large target platform, and in 3.4 demonstrated the slowness in opening and switching between launches in the dialog. In other words, it is much better by my observation.
(In reply to comment #27) > I installed 3.5 and I find the Run Configurations dialog is still incredibly > slow, to open and to type text in fields. IMO this bug should be reopened. > There were definite improvements in 3.5. If you are still have signficant performance problems, please open a new bug with a description of your workspace setup and what aspects of the dialog are slow (opening, switching tabs, editing specific tabs, etc.)
