Community
Participate
Working Groups
I've about 200 launch configurations in my workspace. When invoking Run > Run Configurations there is a 5 second period where the Eclipse UI is unresponsive and the spinning circle cursor is shown. I wonder what is going on there.
Is this consistent each time you open the dialog? Is it slower on the first invocation? What sort of launch configuration is selected whey you open the dialog?
Good questions, Darin. 1: It is consistent (i.e. happens every time) 3: The delay only occurs when the last launch config was of the type "Eclipse Application". It does not occur with Java Application or JUnit. I've about 15 entries in Eclipse Application, 30 in Java application, the rest are JUnit tests. 2: I think the first time is maybe a seconds longer. I also observed that the delay is reproducible just by selecting different entries under 'Eclipse Application' when the dialog is open. The cursor will switch to the spinning cicle for a few seconds. Compare with selecting differnt Java Applications - that is noticeably faster.
I've experimented a bit more and wanted to share my results. - I'm opening the "Run Configurations" dialog and switching between different "Eclipse Application" launch configs - The delay is most noticeable when "plugins selected below only" is choosen in the Plug-ins tab - Using a profiler, I could see that about 50% of the total time to update the dialog is consumed in PluginBlock, specifically the inherited AbstractPluginBlock.initializeFrom(...) and APB.handleFilterButton(). I'll take a shot at this in during my xmas break. Currently just picking different launch configs will slow things down a few seconds each time. I haven't looked at the code yet, but my idea would be to try and make this (i.e. populating the tree lazy). For example to do it when the tab is opened. Or if it's needed to launch, to do when launching.
What build are you testing on? There is nothing wrong with debug here. The problem is the Eclipse launch configuration tabs. We did some work for 3.5.1 to improve things (bug 229073 ) but there are still issues. I don't expect to see anything major changed here for 3.6. It would be great if you stumble upon a hotspot that could be changed without overhauling the tab/block, but none of the committers appear to have time to work on this.
I've tested this with 3.5.1. What I would like to try is reworking the plug-ins tab, to make initialization of the tree lazy (i.e. when the tab is opened). This currently eats up 50% of the time to show the an "Eclipse Applications" launch config. It only happens when the "plug-ins selected below only" option has been picked for that launch config (i.e. there is a noticeable delay to show those). I think the PluginBlock class is from PDE, so I'm ok with moving it over to them. I don't expect anybody to work on this :-), but I plan to submit a patch after xmas.
Part of the fix in bug 229073 was to make the loading of the tree be lazy. In new configs, the tree isn't loaded unless the combo is changed to enable the tree. I spent a good chunk of time trying to get the tree to lazily load on tab activation, but there were some significant obstacles: 1) The plugins tab is a public class, so any changes need to remain binary compatible and should try to keep the current functionality. 2) If the table is not yet initialized and applyChanges is called, we have to make sure we can put the correct values into the config. If the only way to do so is to initialize the table, we'll have gained nothing. 3) Each time the launch config is opened, the list of plug-ins to populate the table with may have changed. I believe that the table is used as a means to determine which config attribute plug-ins should be added (workspace/external and checked/unchecked). Because of (2), we might have to implement a way to do the calculation without requiring the tree. There are also two related issues being looked at: 1) Bug 284885 will hopefully add a new option to manage the config using features. The new UI should be cleaner and faster. If the UI is well received, we may redo the plug-in tree UI. 2) As part of some work I'm doing on target platforms there may be a better performing implementation of FilteredCheckboxTree that the tab could use. Since it was reported that the current implementation could take as much as 50% of the cpu work when opening the config, a change of implementations could be a satisfactory fix.
As far as improvements go, I'm not sure if this has already been done in newer releases, but I'm working with 3.4.2 and the loading blocks the UI. The same is true of the target platform selection preference page. In both cases, could this work be moved to a job, instead of staying on the UI thread? Similar to what's done in the "Import project into workspace" dialog - there's a progress bar, the UI is still responsive, and you can cancel (in 3.6). Even though moving the work to a job will not really affect the actual performance, it greatly improves user experience - there's no wondering if the workbench is deadlocked and needs to be manually killed.
I'm running 3.6 on win7. If I have recently launched an eclipse application, then opening the run dialog hangs eclipse. After waiting 10 minutes or so I finally kill it. This problem goes away if my last run configuration was testNG or Ant. In that case the dialog will open quickly and I can make changes. However, if I choose to flip to the Eclipse Application launch configuration it takes much time to open. (It does not hang eclipse, just takes 5 minutes or so to display and consumes the UI thread.) This is killing productivity. Any ideas on how to improve this from a users perspective are welcome. Thanks!
(In reply to comment #8) > I'm running 3.6 on win7. If I have recently launched an eclipse application, > then opening the run dialog hangs eclipse. After waiting 10 minutes or so I > finally kill it. This problem goes away if my last run configuration was > testNG or Ant. In that case the dialog will open quickly and I can make > changes. However, if I choose to flip to the Eclipse Application launch > configuration it takes much time to open. (It does not hang eclipse, just > takes 5 minutes or so to display and consumes the UI thread.) > > This is killing productivity. Any ideas on how to improve this from a users > perspective are welcome. Thanks! How many plug-ins are in your workspace and target platform? After the tabs were made to lazy load where possible (3.5), the number of performance issues experience decreased significantly. Does your launch config select a subset of plug-ins on the plug-ins tab? Do you have tracing options set? It would helpful to find out which tab is causing your issue.
(In reply to comment #9) > (In reply to comment #8) > > I'm running 3.6 on win7. If I have recently launched an eclipse application, > > then opening the run dialog hangs eclipse. After waiting 10 minutes or so I > > finally kill it. This problem goes away if my last run configuration was > > testNG or Ant. In that case the dialog will open quickly and I can make > > changes. However, if I choose to flip to the Eclipse Application launch > > configuration it takes much time to open. (It does not hang eclipse, just > > takes 5 minutes or so to display and consumes the UI thread.) > > > > This is killing productivity. Any ideas on how to improve this from a users > > perspective are welcome. Thanks! > > How many plug-ins are in your workspace and target platform? After the tabs > were made to lazy load where possible (3.5), the number of performance issues > experience decreased significantly. Does your launch config select a subset of > plug-ins on the plug-ins tab? Do you have tracing options set? > > It would helpful to find out which tab is causing your issue. Hi - I've got 243 out of 1031 plugins selected with 23 out of 29 in the workspace selected and the rest in the target platform. I also have about 28 other java and web projects in the eclipse workspace which obviously do not show up as plugins in the run dialog. These are used in other parts of the application I develop. I only have 2 launch configurations for eclipse applications and several for Tomcat, TestNG, JUnit and Java. I do not have tracing options set when I start eclipse, nor in the launch configuration. The Main tab comes up by default when I open the launch configuration. This morning it took just under ten minutes to open. Once open, I can switch between tabs at will with barely a moment's hesitation. I can also switch between launch configurations with about a 3 second pause. I obviously have a lot of plugins installed since I have RTC, Eclipse, Pydev, TestNG and other plugins and features installed. Can I provide any more information? Many thanks!
(In reply to comment #10) > The Main tab comes up by default when I open the launch configuration. This > morning it took just under ten minutes to open. Once open, I can switch > between tabs at will with barely a moment's hesitation. I can also switch > between launch configurations with about a 3 second pause. > > I obviously have a lot of plugins installed since I have RTC, Eclipse, Pydev, > TestNG and other plugins and features installed. > > Can I provide any more information? > > Many thanks! Thanks for the extra information. Unfortunately I don't have any solutions for you. That isn't a massive number of bundles, but I expect that it is still the plug-ins tab causing slowdown. All the tab content is loaded when the launch configuration dialog is opened. You can confirm that it is the plugins tab causing the problem by comparing how long it takes to open a Eclipse launch config with 'all workspace and enabled target plug-ins' set on the plug-ins tab. It would be great to redo that checkbox tree, but there isn't enough committer time available.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
