-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[performance] JDT initialization blocks IDE startup #1860
Comments
I would like to see initialize deferred, but i don't know why you are looking at getPartent() specificly. As far as i understand any line between e4.compatibility and initializeContainer could be blamed:
And there are other usecases where initialize is also called before UI is shown. For example:
|
Because it is the first call somewhere in UI and the problem is gone if I comment out this specific line.
This is creating the UI (what is hard to delay if we want to see something) the same for a lot of stuff up from there..
That is sadly the case yes... see for example: |
A clean solution might asynchronously update the UI once JDT is fully initialized. |
I just noticed many people including you and @vogella are always concerned about IDE startup times and this one can have a huge impact (its not only PDE affected but also m2e and JDT itself) as much stuff is loaded and initialized and as it even blocks the UI thread the loadscreen is also not updated. So I decided to at least report the problem :-) |
Thanks for reporting. I definitely would like to see it fixed. |
You can also trace the activator startup time per bundle: see https://www.vogella.com/tutorials/EclipsePerformance/article.html#example-tracing-the-startup-time-of-plug-ins |
The activator is not the problem here. I noticed another undesirable side-effect: Actually jdt UI plugin has a job that should batch initialize all classpathcontainers for performance reasons with
but because this is an UI Workbench job it is called after the UI is created, due to the calls to the classpath containers already while creating the UI some are already initialized the "slow" way without batching, afterwards the job is run and performs the init of the other containers (if any). |
org.eclipse.jdt.ui.StandardJavaElementContentProvider.getParent(Object) calls this code
eclipse.jdt.ui/org.eclipse.jdt.ui/ui/org/eclipse/jdt/ui/StandardJavaElementContentProvider.java
Line 246 in 4dc72d8
the existence check currently triggers all classpath containers of all projects to be resolved what is a costly operation and blocks the whole IDE startup procedure see here:
instead one needs a more lightweight check or even always return
null
as allowed by the API or a better way to determine the parents.The text was updated successfully, but these errors were encountered: