Community
Participate
Working Groups
In my workspace I have 24 projects. In each case, the java build path contains about 20 or more jar files from a target platform which I am extending with new plugins. I have one java perspective, which contains the following views: packages, navigator, outline. In the shortcut bar, I have the tasks, search, and repository view. There are no editors open. It takes about 20 seconds to start up. If I open the JavaEditor class using Open Type.., a java edior opens on the class and the hierarchy view opens. If I close the editor, shutdown, and restart, it takes me 8 minutes to restart. If I close the hierarchy view, shutdown, and restart, it takes about 20 seconds to start up. I am now afraid to shutdown eclipse with the hierarchy view open. Please help me.
need to measure type hierarchy start up. I assume it will be difficult to make your workspace available to us? If not could you do me the favor and do some ctrl-breaks in the console during the start-up and paste them into the bug report. The fallback is to not persist the type hierarchy view.
Created a full source workspace with 47 projects, 9847 .class files from 6346 .java files... to startup the workspace took 27 seconds. Opening a hierarchy view on Object took 2 minutes before the view showed life & the disk settled down and another 4:15 before it was finished (6:15 total). Starting up the workspace with the hierarchy view open took 6:15. It doesn't appear that something else is happening at startup. David: Did the hierarchy view open 'quickly' for you (1-2 min) then take 8 minutes on startup?
Sorry for the delay. I am trying to copy my workspace, but everytime I do I run out of space. It looks like you have a sample case yourself, though. If I open JavaEditor, it takes about 10 s for the view to appear.
Created a full binary workspace with 47 projects, 52 zip files and 68 jar files... to startup the workspace took 22 seconds. Opening a hierarchy view on Object took 30 seconds before the view showed life & the disk settled down and another 2:30 before it was finished (3:00 total). Starting up the workspace with the hierarchy view open took 3:17. I'm definitely not seeing anything different on startup.
Tried reproducing the problem with a copy of David's workspace but had no luck. The startup time is the same as the time taken to open the hierarchy in the workbench... around 15-20 seconds.
Some notes on why the hierarchy of Object takes so long to display: - computing the hierarchy takes ~2 minutes - expanding to level 2 (current default) instead of level 1 in TraditionalHierarchyViewer.updateContent takes 4.5 MINUTES! *** Should configure whether subtypes are visible based on the number of subtypes... the hierarchy browser is still useful and it lets the user decide if he really wants to see the subtypes.
So its taking roughly 4:30 to expand to level 2 instead of 1... It takes 2:45 to sort the 3240 subtypes... ALL of it (well only 2:44) can be eliminated by changing TypeHierarchyViewer$1.category(Object element) to not distinguish between classes and interfaces: if (element instanceof IType) { // try { // return (((IType)element).isInterface()) ? 2 : 1; return 1; // } catch (JavaModelException e) { // }... The isInterface call requires that every type is parsed into the JavaModel... that leaves 1:45 to put the subtypes in the tree.
So a couple simple things to speed up large hierarchies: 1. Only expand to level 1 when there are too many subtypes. 2. Stop sending isInterface() to every type (in TypeHierarchyViewer$1.category ()) and thus parsing everything into the JavaModel. It still takes 1:45-2:00 to send createTreeItem() to all 3240 subtypes... there is likely something else which can be skipped when adding a type.
*** Bug 12043 has been marked as a duplicate of this bug. ***
we got additional support from JavaModel that allows us to get the interface status and the flags without populating the JavaModel. We will implement a custom LabelProvider that uses ITypeHierarchy.getCachedFlags (IType). Notice, that we tried the option to not persist the type hierarchy but users noticed.
*** Bug 16647 has been marked as a duplicate of this bug. ***
to avoid populating the Java model we will remove support for showing the running man in the type hierarchy. Testing for main would result in populating the Java model.
Changed the hierarchy view to use the new API to avoid populating the Java model. Improved from 80 seconds to 25 seconds. (opening java.util.Object on a selfhosting workspace)
The hierarchy input is now persisted again, but only for input types with less than 1000 subtypes (excludes java.lang.Object) released > F1
pls verify
Please verify and close if possible. Otherwise reopen.
Verified.
