[Fix #122] Don't auto-expand InspectorView class hierarchy for java.lang.Object #127
Conversation
|
@jasonk000 or @krumts: if one of you can please review when you have a chance, thanks! ECA is down again but we know why that check is failing now. It was up earlier today for PR #124 and I just did |
…y for java.lang.Object Signed-off-by: Kevin Grigorenko <kevin.grigorenko@us.ibm.com>
There was a problem hiding this comment.
Good find!
Change LGTM if you want to proceed.
I also propose a slight alternative, that should more safely do this for any class that is selected, by only opening to one-level below the class.
- classHierarchyTree.expandAll();
+ // value 2 expands one level deeper than selected class
+ int levelsToRoot = findIClassLevelsToRoot(input);
+ classHierarchyTree.expandToLevel(2 + levelsToRoot);
and
+ private static int findIClassLevelsToRoot(IClass input)
+ {
+ int levelsToRoot = 0;
+ IClass parent = input.getSuperClass();
+ while (parent != null)
+ {
+ levelsToRoot++;
+ parent = parent.getSuperClass();
+ }
+ return levelsToRoot;
+ }
Resulting view, everything is expanded to one-below the selected item, in this case the selected item is the thread object
I tested the three approaches:
So opening to one-level below is much faster than the current behavior though even with a relatively small heap dump, it was nearly noticeable, and this will scale with the number of classes with larger heaps. I could imagine this could get into the hundreds of milliseconds range which is not too big a deal but might get noticeable. Also worth noting that this is done even if the Class Hierarchy view is not visible. On the flip side, your solution is more generic and would handle the cases of a class that's not |
…epth Signed-off-by: Kevin Grigorenko <kevin.grigorenko@us.ibm.com>
|
Updated commit and ran full tests locally |
Fixes #122 performance issue