Poor Performance of Quick Outline View

[HeikoKlare]

Current Behavior

The quick outline view (Ctrl+O) opens very slowly when the opened class is part of a large class hierarchy. The root cause seems to be a combination of two things:

1. Loading the complete view is performed synchronously, thus the UI freezes while loading it. --> Asynchronously decorate quick outline view via DecorationManager #1922 eclipse-jdt/eclipse.jdt.ui#1929
2. The action calculates the complete inheritance hierarchy of involved classes in order to show the "method overwrite indicator" labels for methods that overwrite methods of superclasses. This information is not cached in the AST and is calculated every time the quick outline view is opened. --> fix slow Quick Outline View #1922 eclipse-jdt/eclipse.jdt.ui#1926.

The ordinary outline view calculates the overwrite indicator labels asynchronously by spawning a decoration job and thus provides the same information but without blocking the UI.

Expected Behavior

The quick outline view shall open instantly and calculate and add additional information asynchronously. It should use the same behavior as in the ordinary outline view to improve responsiveness of the UI.
While loading the information in background, there should be an indicator that the view has not completely loaded all expected information in the quick outline view yet.

Additional Information

This is related to #3.

Existing Workaround

Disable "Java Method Overwrite Indicator" label.

[MaxEKramer]

In addition to the described problem that the outline view is slow in projects with a lot of code I found out that the first run is even slow for small projects:

First usage of (Quick) Type Hierarchy is slower than later usages

Observed Behavior:
If the Type Hierarchy is used on a reasonably sized workspace with Java projects (e.g. the one for the Platform SDK) it will take one or two seconds to pop up. If it is opened again (on the same or another Java class) a second, third time and so one it shows up immediately. The same holds for the Quick Type Hierarchy.

Expected Behavior:
We can assume that the Type Hierarchy will always be opened at some point of time if the Java perspective is open. Therefore, the calculations necessary for showing the Type Hierarchy should already be performed before it is actually opened. This way the first usage will be as fast as the later usages.

[fedejeanne]

@HeikoKlare I think Jörg meant this issue in his comment.

I'm looking into adding a reproducer for this and a VVM sample.

[fedejeanne]

A sample and the steps to reproduce have been added in our internal bug-tracker to avoid showing any internal data.

I have exported the FW calls of the sample though, here's a CSV with the data concerning only the main (UI) Thread.
Slow outline view (FW calls).zip

An initial analysis tells me that there are several performance issues playing a role here so it might be worth splitting this issue in smaller chunks. Here's a screenshot of the hotspot methods:

Even though JavaModelManager also plays a role, it is not a problem with getZipFile so I don't expect a performance boost when Jörg's PR is merged (eclipse-jdt/eclipse.jdt.core#1615)

[fedejeanne]

@HeikoKlare in eclipse-jdt/eclipse.jdt.ui#933 (comment) you mentioned that...

when I once took a first look into samples, I also saw that quite some time is spent on comparing class files when retrieving them from hash maps.

Which method is that? Can you post a screenshot from the sample I added in T3y?