Poor Performance of Quick Outline View #1922
Comments
|
Can you please try to give a simple selfcontaining reproducer like eclipse-jdt/eclipse.jdt.core#3327 (comment) instead of attachments. Also please add screenshots of sampling result (call tree + hotspots), ideally add stacktrace of hotspot as text. |
|
I wasn't able to provide a self contained reproducer since the problem here only arises because of the sheer amount of classes and methods that need to be analyzed. Just to give you an idea of the complexity, the ZIP I provided (which is just a small part of the real issue) contains 1.138 of our own classes which are discoverable by navigating 1 class up the hierarchy and gathering (most of) the classes that the classes in the hierarchy know and need (again, our own classes, no JDK/Eclipse classes). Some screenshotsSmall reproducerThe problem seems to be deep down in the
Bigger sample (in our WS)The sample from our big WS paints more or less the same picture but it only goes as deep as
|
|
A thousand classes does not sound like really many. It rather sounds that there is some loop in the hierarchy such that same Classes are visited multiple times. The shown hotspots do not include any I/O which is unlikely. Maybe you have excluded java.* from sampling? |
|
i also do not understand that getEntryAfterMiss shows the same Total time as Self Time while it calls a lot of other staff. somethings wrong with that sampling data, All selftimes should add up to the total time. |
|
if you add |
I added this output to
And pressed class A {
public void myMethod() {}
}
class A2 extends A{
@Override public void myMethod() {}
}And then grouped the results and counted them with Excel. Here's the result: Grouped calls
What surprises me is that there are several unnecessary things in there, like other classes/files (
I resampled the big WS and I see more or less the same as before (and still no reference to
I didn't skip
|
don't visit redundant superinterfaces more then once eclipse-jdt#1922
This speeds up the quick outline. Fixes eclipse-jdt#1922
This speeds up the quick outline. Fixes eclipse-jdt#1922
This speeds up the quick outline. Fixes eclipse-jdt#1922
…pse-jdt#1922 The Quick Outline View currently applies (i.e., calculates and draws) decorations for override indicators synchronously. In case the calculation of the indicator takes long, it blocks the UI. The ordinary Outline View defers the responsibility of calculating and applying decorations to the DecorationManager. This ensures that (1) that task is performed asynchronously via a dedicated job and (2) that the decoration manager takes care of the current user configuration (i.e., whether those indicators shall be shown or not), which the Quick Outline View currently replicates. With this change, the Quick Outline View uses the same label decorator as the ordinary Outline View, which makes the DecorationManagager process the override label decorator asynchronously instead of applying it synchronously. Contributes to eclipse-jdt#1922
…pse-jdt#1922 The Quick Outline View currently applies (i.e., calculates and draws) decorations for override indicators synchronously. In case the calculation of the indicator takes long, it blocks the UI. The ordinary Outline View defers the responsibility of calculating and applying decorations to the DecorationManager. This ensures that (1) that task is performed asynchronously via a dedicated job and (2) that the decoration manager takes care of the current user configuration (i.e., whether those indicators shall be shown or not), which the Quick Outline View currently replicates. With this change, the Quick Outline View uses the same label decorator as the ordinary Outline View, which makes the DecorationManager process the override label decorator asynchronously instead of applying it synchronously. Contributes to eclipse-jdt#1922
…pse-jdt#1922 The Quick Outline View currently applies (i.e., calculates and draws) decorations for override indicators synchronously. In case the calculation of the indicator takes long, it blocks the UI. The ordinary Outline View defers the responsibility of calculating and applying decorations to the DecorationManager. This ensures that (1) that task is performed asynchronously via a dedicated job and (2) that the decoration manager takes care of the current user configuration (i.e., whether those indicators shall be shown or not), which the Quick Outline View currently replicates. With this change, the Quick Outline View uses the same label decorator as the ordinary Outline View, which makes the DecorationManager process the override label decorator asynchronously instead of applying it synchronously. Contributes to eclipse-jdt#1922
don't visit redundant superinterfaces more then once eclipse-jdt#1922
fedejeanne
changed the title
|
Reproducer: one needs 2 files, the ReproducerGitHub1922RedundantTypeHierarchy must not be open in editor (to not use AST for computation). |
don't visit redundant superinterfaces more then once #1922
The Quick Outline View currently applies (i.e., calculates and draws) decorations for override indicators synchronously. In case the calculation of the indicator takes long, it blocks the UI. The ordinary Outline View defers the responsibility of calculating and applying decorations to the DecorationManager. This ensures that (1) that task is performed asynchronously via a dedicated job and (2) that the decoration manager takes care of the current user configuration (i.e., whether those indicators shall be shown or not), which the Quick Outline View currently replicates. With this change, the Quick Outline View uses the same label decorator as the ordinary Outline View, which makes the DecorationManager process the override label decorator asynchronously instead of applying it synchronously. Contributes to #1922
(See issue #2 our internal backlog)
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:
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.
Existing Workaround
Disable "Java Method Overwrite Indicator" label.
Samples and reproducer
To reproduce, do the following:
Broke1and clickCtrl+otwiceThis is the sample I got: Broke1-I20241230-1800.zip
I also sampled in our big WS (~2.000 plugins and fragments), it takes 757s to open the quick outline view:
MyECU_2025-03-M1.zip
The text was updated successfully, but these errors were encountered: