search

vi-eclipse / Eclipse-JDT

Umbrella repository for managing a backlog of Eclipse-JDT-related features/issues
0 stars 0 forks source link

Poor Performance of Quick Outline View #2

Open HeikoKlare opened 1 year ago

HeikoKlare commented 1 year ago

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.
  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 everytime the quick outline view is opened.

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.

8455de56-acf9-4dab-a1ad-1c94e1bfcced

MaxEKramer commented 1 year ago

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 commented 10 months ago

@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 commented 10 months ago

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:

image

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 (https://github.com/eclipse-jdt/eclipse.jdt.core/pull/1615)

image

fedejeanne commented 10 months ago

@HeikoKlare in https://github.com/eclipse-jdt/eclipse.jdt.ui/pull/933#issuecomment-1825488896 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?