Community
Participate
Working Groups
Created attachment 79889 [details] Thread dumps taken by Philippe while "Initializing Java Tooling" was running In bug 188712 comment 14, Philippe reported that "Initializing Java Tooling" was taking a long time. The attached thread dumps show that this is because the PDE container initializer takes a long time. Eric, please investigate if the PDE container can be improved.
Build: I20071002-1342
Test case to reproduce the same lock as per Philippe's dump. 1 - launch a debug session against a new workspace 2 - import jdt.core plugin with source 3 - open any Java file 4 - leave the Java editor open, and shutdown your debug session 5 - check-out org.eclipse.pde.core 6 - place a breakpoint in PDEState#readTargetState(URL[], IProgressMonitor) at line 93 7 - start the debug session 8 - once stopped at BP, and debug session UI is visible, open the Progress view --> the Initialization of Java Tooling is blocked at 0%, the step in-progress is " Configuring plug-in dependencies " 9 - pause the thread that is running JavaCore#initializeAfterLoad(IProgressMonitor) notice the debug stack leads to (PDE) PluginModelManager#initializeTable() Both threads (1 running, 1 waiting) access the same synchronized method: - 1 thread to reconcile the Java editor - 1 thread to init the Java Tooling
Move to PDE/UI
This problem is a source of constant annoyance. Every time I start Eclipse (I'm developing for multiple versions, so this is often) the UI will hang for 10-15 seconds.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Still relevant, I think. PDEState#readTargetState no longer exists, but PluginModelManager#initializeTable may still block the startup. In the launch I just sampled, it was triggered on the UI by the Package Explorer (via JavaProject#resolveClasspath). The initialization will probably always be triggered somewhere on the startup path, but maybe its performance can be improved a bit. In my workspace it takes ~20s (with ~1500 entries each in WS and target). Sample shows that nearly all time is spent on opening ZipFiles to read the manifest.
Created attachment 279531 [details] CPU sample of startup
Looks like the issue is not reading the manifest, but doing it multiple times for each bundle. With my workspace loadManifest is called 12 times per file on average during initializeTable.
Created attachment 279559 [details] trace of TP resolving I've added a couple of trace points which produced the attached result. From there the performance issue is obvious... The target definition I used contains four update sites. The performances scales quadratically with the number of update sites, because they all share the same synchronizer which synchronizes the whole target every time.
*** Bug 516795 has been marked as a duplicate of this bug. ***
(In reply to Julian Honnen from comment #6) > Still relevant, I think. > > PDEState#readTargetState no longer exists, but > PluginModelManager#initializeTable may still block the startup. In the > launch I just sampled, it was triggered on the UI by the Package Explorer > (via JavaProject#resolveClasspath). > > The initialization will probably always be triggered somewhere on the > startup path, but maybe its performance can be improved a bit. > In my workspace it takes ~20s (with ~1500 entries each in WS and target). > Sample shows that nearly all time is spent on opening ZipFiles to read the > manifest. Julian, can you give steps for recreating this?
(In reply to Vikas Chandra from comment #11) > Julian, can you give steps for recreating this? Should be enough to use a target definition containing multiple software sites. If you set a breakpoint on IUBundleContainer::cacheBundles, it should be hit repeatedly during startup for the same container.
(In reply to Julian Honnen from comment #12) > (In reply to Vikas Chandra from comment #11) > > Julian, can you give steps for recreating this? > > Should be enough to use a target definition containing multiple software > sites. If you set a breakpoint on IUBundleContainer::cacheBundles, it should > be hit repeatedly during startup for the same container. OK thanks for it. comment#2 was for not for target definition. So is this a different problem?
(In reply to Vikas Chandra from comment #13) > comment#2 was for not for target definition. So is this a different problem? Not sure, but it behaves similarly when you use that target definition for the workspace. Somewhere during startup (or initializing java tooling), the workspace target gets resolved, hitting this performance issue. If they had this exact issue back then, I don't know.
Julian, any news here? Would be nice to have that startup bump reduced.
(In reply to Lars Vogel from comment #15) > Julian, any news here? Would be nice to have that startup bump reduced. Nothing yet, but I hope to get something done by M1. Note though, that you need a target with multiple P2 repos to hit this issue at all. This does not affect targets based on an installation or oomph targlets.
(In reply to Julian Honnen from comment #16) > (In reply to Lars Vogel from comment #15) > > Julian, any news here? Would be nice to have that startup bump reduced. > Nothing yet, but I hope to get something done by M1. > > Note though, that you need a target with multiple P2 repos to hit this issue > at all. This does not affect targets based on an installation or oomph > targlets. Sorry to hear that I have to live with the relative long time the PDE container initializes at startup. I use the IDE as target.
(In reply to Lars Vogel from comment #17) > Sorry to hear that I have to live with the relative long time the PDE > container initializes at startup. I use the IDE as target. Please update your bug 552788 for that. A target with an eclipse SDK installation resolves in 100ms for me.
New Gerrit change created: https://git.eclipse.org/r/154729
Gerrit change https://git.eclipse.org/r/154729 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=e35854c617d51c42fa806f938970ae9020733b49
(In reply to Eclipse Genie from comment #20) > Gerrit change https://git.eclipse.org/r/154729 was merged to [master]. > Commit: > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=e35854c617d51c42fa806f938970ae9020733b49 > Is this the final fix for this bug? If so, please close it.
Julian, Thank you so much! I have just been having a quick try with I20200106-1805 on my workspace containing all of CDT and its dependencies (~1000 bundles) and the start time to a useable workspace is dramatically improved. My test case of starting Eclipse with the Plug-ins view open, Pressing Ctrl-Shift-T as soon as IDE opens and then waiting for the dialog to be populated (finished indexing and Plug-in view populated) has gone from about 25s to less than 10s. For me this is a game changer because I had started to use VS Code if I just wanted a quick peek at a few files because of this startup time, but I would rather be able to use Eclipse. I will try it on Windows sometime soon, on Windows when I reported Bug 516795 it was much worse. I suppose someone can mark this as verified now. Jonah
(In reply to Jonah Graham from comment #22) Thanks, Jonah! What does your target definition look like? I.e. how many p2 repositories does it contain?
verified based on comment#22
(In reply to Julian Honnen from comment #23) > What does your target definition look like? I.e. how many p2 repositories > does it contain? https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/releng/org.eclipse.cdt.target/cdt.target It has 17 p2 repos.
