Community
Participate
Working Groups
build I20031113 - with UI projects in source - open type on ActionFactory (in org.eclipse.ui.actions) - Ctrl+O - it takes 4 seconds to come up on my laptop (T30)
We already noticed this as well and plan to investigate. We first thought it might be a bottleneck when filling the tree but the Outline is fast when opened on a large class file (e.g. StyledText).
Might be due to the large number of inner classes. The filter checks if any leaf elements are visible for each ancestor.
That might be. I there anything we can do on our side? We noticed that when we enter a filter pattern and then remove char by char it takes several seconds when the last char is removed.
When the last char is removed, it shouldn't need to do any filtering or recurse through the children. Probably need to profile this.
Observed the following: - open AbstractTextEditor - Ctrl+O - type "i" to reduce the number of choices - press backspace -> note that the update of the entire tree (even though already computed) takes a long time, with the hourglass cursor flashing (on linux). -> a thread dump reveals that most of the time is spent in calls from the label decorator called when the items are updated: -------- partial stack dump from the main thread ------------- <<< here it goes on into the core internals that re-compute the hierarchy >>> at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:533) at org.eclipse.jdt.internal.core.SourceType.newSupertypeHierarchy(SourceType.java:501) at org.eclipse.jdt.internal.corext.util.SuperTypeHierarchyCache.getTypeHierarchy(SuperTypeHierarchyCache.java:70) - locked <0x482de298> (a java.util.ArrayList) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.getOverrideIndicators(OverrideIndicatorLabelDecorator.java:134) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.computeAdornmentFlags(OverrideIndicatorLabelDecorator.java:118) at org.eclipse.jdt.ui.OverrideIndicatorLabelDecorator.decorateImage(OverrideIndicatorLabelDecorator.java:92) at org.eclipse.jdt.internal.ui.viewsupport.JavaUILabelProvider.decorateImage(JavaUILabelProvider.java:119) at org.eclipse.jdt.internal.ui.viewsupport.JavaUILabelProvider.getImage(JavaUILabelProvider.java:134) at org.eclipse.jface.viewers.DecoratingLabelProvider.getImage(DecoratingLabelProvider.java:73) at org.eclipse.jdt.internal.ui.viewsupport.DecoratingJavaLabelProvider.getImage(DecoratingJavaLabelProvider.java:103) at org.eclipse.jface.viewers.TreeViewer.doUpdateItem(TreeViewer.java:99) at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:87) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1123) at org.eclipse.core.runtime.Platform.run(Platform.java:461) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:469) at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:119) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1123) at org.eclipse.core.runtime.Platform.run(Platform.java:461) at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:1285) <<< invoked when the tree gets re-expanded >>>
in fact, every stack dump i obtained while showing the quick outline or modifying the filter expression showed being inside OverrideIndicatorLabelDecorator.getOverrideIndicators(OverrideIndicatorLabelDecorator.java:134) I suspect that the override indicator computation takes so much time.
when turning off override indicators in Java->Appearance, the time to pop-up the outline or restore the view as described above (by deleting the filter expression), the time used is reduced from 5s to 1s (redhat linux, 2+ GHz, 0.7 GB).
This has been fixed a while ago.
start verifying
verified ok
