Community
Participate
Working Groups
Created attachment 269614 [details] Test project Using Eclipse SDK 4.8-I20170731-2000 and 4.7.0. This is a bit similar to bug 444137. When starting Eclipse with a opened Java file that depends on a target platform, startup time is very long. While profiling it, I noticed > 70% of the time is spent in resolving the target platform in the UI thread (in a CDT workspace). To reproduce: 1. Import attached project 2. Open target file, Set as Target Platform 3. Open the TestClass.java file (keep it open) 4. Restart Restarting takes a while. Now if you close the Java file and restart, it will be much quicker. In the smaller test project I attached, the difference is 15s compared to 33s (quad core, 8GB RAM, SSD laptop). Note: the target in the attached project is quite big as I was unsure if the delay was proportional to the size of the target or not. I will also attach a screenshot of the profiling session from YourKit.
Created attachment 269615 [details] Yourkit screen shot
I also noticed this recently, with the "default" running platform target. I believe tbis is not 4.7, but much older issue, let say 3.8.2. The problem here is probably higher in the stack and not in PDE. Probably PackageExplorerContentProvider.elementChanged should not run in UI thread, or even higher in JDT core DeltaProcessor shouldn't process events in UI thread too.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
At the top of the call chain the editor seems to need results, so at this level synchronous behavior can probably not be avoided? Further down, callees are certainly not aware that they run on the UI thread, JavaModelOperation in particular doesn't even know the first bit about UI threads, as this is in a headless component. PackageExplorerContentProvider, OTOH, already distinguishes: are we on the UI thread, then process deltas here and now, otherwise updates are scheduled and posted via postAsyncUpdate(). This looks good to me. I still see a slight chance that DeltaProcessor.firePostChangeDelta() could be called in a new Job. IMHO, such a change would need extensive testing. I s.o. fells to be up to the task, feel free to re-open and move to JDT/Core.
