Community
Participate
Working Groups
The hierarchy may be constructed to have a huge number of nodes. Atomatical expanding the entire tree may hang Eclipse or crash it with out-of-memory. See test project TypeHierarchyTest attached to https://bugs.eclipse.org/bugs/show_bug.cgi?id=469668 Load that project into workspace and try to show supertype hierarchy for interface hierarchy.I20. It will take cpu for a long time, and most probably hang Eclipse. The project contains only 20 sources - interfaces extending each other.
Not a regression compared to 3.x.
New Gerrit change created: https://git.eclipse.org/r/72504
Restricted the expansion to level 2, similar to the subtype hierarchy (as done in bug 31897). Dani, please have a look.
(In reply to Noopur Gupta from comment #3) > Restricted the expansion to level 2, similar to the subtype hierarchy (as > done in bug 31897). Dani, please have a look. This will reduce the usability for more users than it helps others. The supertype hierarchy is usually smaller than the subtype hierarchy. Did you investigate what exactly takes that long? Maybe we can find a dynamic limit, or expand as much as fits into the visible area. If not, we can set a limit, but higher, e.g. 5.
(In reply to Dani Megert from comment #4) > (In reply to Noopur Gupta from comment #3) > > Restricted the expansion to level 2, similar to the subtype hierarchy (as > > done in bug 31897). Dani, please have a look. > > This will reduce the usability for more users than it helps others. The > supertype hierarchy is usually smaller than the subtype hierarchy. > > Did you investigate what exactly takes that long? > > Maybe we can find a dynamic limit, or expand as much as fits into the > visible area. If not, we can set a limit, but higher, e.g. 5. Another solution could be to expand node-by-node and remember the nodes that are fully expand and when we see the same node again later in the tree, we don't expand it.
(In reply to Dani Megert from comment #5) > (In reply to Dani Megert from comment #4) > > (In reply to Noopur Gupta from comment #3) > > > Restricted the expansion to level 2, similar to the subtype hierarchy (as > > > done in bug 31897). Dani, please have a look. > > > > This will reduce the usability for more users than it helps others. The > > supertype hierarchy is usually smaller than the subtype hierarchy. > > > > Did you investigate what exactly takes that long? YourKit shows that all the time is spent in recursive calls to AbstractTreeViewer.internalExpandToLevel(Widget widget, int level) and other methods called from it like #createChildren(Widget widget, boolean materialize) etc. The view finally shows the complete expanded supertype hierarchy but only after an hour or so. It is just the huge number of recursive calls to #internalExpandToLevel due to the nature of the hierarchy in this example. > Another solution could be to expand node-by-node and remember the nodes that > are fully expand and when we see the same node again later in the tree, we > don't expand it. Uploaded patch set 2 on Gerrit with this behavior. Smaller example to see this: package hierarchy; public interface I1 extends X, A {} interface X extends Y {} interface Y extends Z {} interface Z {} interface A extends Y {} Dani, please have a look.
+1 to consider this fix for RC2. Markus or Stephan, please provide the second +1 and review. Thanks.
I agree that this should be fixed in RC2, and I agree with the fix strategy (only expand the first occurrence of any given type in the hierarchy), but I disagree with relying on undocumented implementation details, see Gerrit comment.
In patch set 3, specifying the exact tree item to expand and using an explicit HashSet to collect the visited elements.
(In reply to Noopur Gupta from comment #9) > In patch set 3, specifying the exact tree item to expand and using an > explicit HashSet to collect the visited elements. +1 for this.
Gerrit change https://git.eclipse.org/r/72504 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=3ecdd3d0efba27ce2a1af15eed82680e2e26c1de
+1. Patch set 3 changed the expansion strategy from breadth first to depth first. For the first visible page in the tree, that results in a state that looks even closer to the full expansion we had in earlier releases.
Verified in eclipse-SDK-I20160518-2000-win32-x86_64.
