Community
Participate
Working Groups
The context menu on the 'Packages' view takes an inordinately long time to appear. The time seems to be proportional to the number of items expanded in the tree view. With a fresh packages view, the menu appears less than one second after right clicking (on a 550MHz Athlon running WinNT). If I expand a about thirty classes, the menu takes more than five seconds to appear! As I expand the tree further, the menu gets even slower. (Tested against 20011219)
The speed seems to depend on how many elements of the tree widget have ever been expanded. Collapsing the tree widget does not make the menu fast again. The only way to restore the original speed is to close the 'Packages' view and re-open it.
I cannot reproduce this. The context menu pops-up fast even when I have hundreds of tree nodes expanded. Questions: Is the speed different dependening on what type of element you select (project, package, CU, member)? Do you have additional plugins installed over the SDK or are you running the vanilla SDK? What other views are visible? Can you reproduce the problem when only the editor and the packages view are open and no other views? Is changing the selectio slow as well once you have many nodes expanded.
It does not seem to matter what kind of nodes are displayed, or what kind of node I right click on. The menu takes longer and longer to appear as I expand more nodes. For a concrete example, I closed all of the views in my Java perspective and opened a new Packages viewer. I right clicked on the first project, and a menu appeared fairly quickly (not instantaneous, but quick enough). I then expanded the project. The first child of the project is an archive variable, JRE_LIB, pointing at the HDK1.3 rt.jar file. I expanded that node and expanded all of the packages from com.ibm.CosNaming to java.lang.ref. Then I scrolled back up to the top and right clicked on the first project again. It took about 4 seconds for the context menu to appear. I then expanded the rest of the java.* and javax.* packages. It took 9 seconds for the first project's context menu to appear. I then expanded the rest of the packages. It took 16 seconds for the first project's context menu to appear. Note that my machine is a relatively slow 550MHz Athlon w/256MB RAM. I'm using HDK1.3 as the VM running Eclipse. Eclipse version is 20011219 (last stable build).
Note: changing the selection also seems to slow down, although not nearly as badly as the context menu. With all the packages in rt.jar expanded, it takes about 1 second to select a node. (And 16 seconds to get its context menu). To get the times that I gave for the context menu I first selected the first project, then I right clicked on it. I'm running a completely vanilla Eclipse install.
I saw the post on eclipse corner about this problem and came to check it out. I definitely experience this problem too. (The first time I open the context menu after selecting an item is the worst - subsequent attempts are much faster. I do not however seem to be affected by the number of expanded nodes. I expand all of SWT and the performance seemed to be the same as with only a few nodes expanded.) Silenio suggested that it may have to do with calls to Program - on KDE we had this disabled for a while and the context menu came up faster. Erich, is the info regarding the node (such as system editor, system icon) cached?
The Open With menu is a standard menu provided by the workbench that we just reuse. Carboned Nick for advise.
I noticed in the Navigator's context menu, that it's doing more work than necessary for the New... submenu, which the packages view also reuses. It's reading the registry each time, although the impact didn't actually seem that bad when I profiled it. It doesn't care about the selection or which elements are in the viewer, so I doubt it's the culprit. The Open With menu may also have problems. I'll have a look. Note that the cost of getting the selection from a Tree is proportional to the number of items in the tree, not the size of the selection. In SWT, it actually iterates over all items. This does not scale well, but I don't see what SWT can do about it since the OS widget was never designed to support multi selection, and having the widget cache OS state is generally a bad idea. Since we lazily populate the widget in the TreeViewer, it's not so bad if the nodes aren't expanded. Many of our actions (in Workbench and in JDT) get the selection each time to update their enablement, or to determine whether they should be added to the context menu. Abstractions like IUpdate or action groups tend to encourage this pattern (which is why I have reservations about pushing IUpdate down into JFace). I will profile this and try to improve any bits that JDT reuses from Workbench, and point out anything else I see. Peter, since you seem to be hit worse than other people, I may come by and profile on your setup, if that's OK.
I was able to reproduce it on Windows using Peter's steps. Veronika, you mentioned Linux, but the OS for this PR is Win NT. It might well be worse on Linux though. Profiling showed the following: - Almost all of the time is in Tree.getSelection() and related SWT SendMessages. This is called 48 times. - JDT: RefactoringAction accounts for 16 of these (via IUpdate) - UI: ObjectActionContributor takes 14 - JDT: JavaSearchSubGroup takes 5 - the rest are about 3/4 JDT, 1/4 UI - see the attached data.html for more details Leaks: - JDT: The getClipboard() methods in PasteSourceReferencesAction and PasteResourceFromClipboardAction leak Clipboard. This probably has no impact on performance though. - UI: ActionContributionItem.fill seems to repeatedly add a listener. - UI: There's some evidence of images being loaded and leaked too. I will investigate the UI ones. We should try to minimize the number of calls to getSelection() both in JDT and in UI. If it's much worse on Linux, perhaps Veronika could investigate why.
See defect 11484 for details on the repeated allocation of images. This could end up being the "image leak"
Created attachment 486 [details] OptimizeIt profile of a single context menu popup on project, with java* and javax* expanded in rt.jar
Created attachment 487 [details] Zip file with profile and icons
We should redo the measurments given that we reorganized the menus and payed attention to reduce the number of getSelection calls.
Erich, will your team do the measurement or would you like me to? Peter, please let us know whether you see an improvement when you switch to the M5 stable build.
Just did a simple test on 20020412: - create Java project - select it - set breakpoint in Tree.getSelection() - pop up menu I tried it in both the Navigator and the Packages view. In the Navigator, it got one in fillContextMenu where it gets the selection for the ActionContext passed to the ActionGroups. It also got a bunch in the object contribution management. It was getting it once for each of the contributions. I've changed this to get the selection once and pass it to all the contributions. So the Navigator now does a total of 2 calls to getSelection(). The Packages view still does 34. Most are due to the continued use of IUpdate.
Also, PackageExplorerPart.saveExpansionState should be changed to use AbstractTreeViewer.getVisibleExpandedElements() instead of getExpandedElements ().
To clarify the previous suggestion, if you use getExpandedElements() it includes -all- expanded elements, including those that are under collapsed elements. So if you use this to persist the state, then the viewer is always populated with all elements you've ever visited, even after shutdown/restart. Using getVisibleExpandedElements() loses a bit of state (the expanded elements under collapsed elements), but it does save the top level expansions which the user sees. Storing just the selection and revealing it on restore is another option, but then you do lose some visible state, e.g. I might have 2 projects expanded but the selection only in one. Using getVisibleExpandedElements() is a reasonable tradeoff between storing every expanded element and storing none.
There's a thread in the newsgroup from earlier today where somebody with a killer fast machine on Win2K is hitting this problem.
The new packages views context menu got released in 20020418. All actions in there (with the exception of the refactoring actions) no longer call getSelection but use the selection from the SelectionEvent. Dirk pls take care of the refactoring actions and verify that getSelection isn't call multiple times anymore.
In Build 20020502 getSelection is only called once per context menu in the packages view. Nick anything else we can do in JDT UI ?
I don't think you can reduce the calls to getSelection() any further <g>. I'll run it under the profiler and see if there are any other improvements to be had.
changed prio, but keep it open. we have done what we can do
fix the component it was JDT-UI but the assignee is from Platform UI
Closing.
