Community
Participate
Working Groups
M5a When I restarted a workbench containing the following (collapsed) projects loaded from HEAD: org.eclipse.core.commands org.eclipse.jface org.eclipse.ui org.eclipse.ui.ide org.eclipse.ui.views org.eclipse.ui.workbench The method PackageExplorerPart#makeActions took 9.85% of my startup time (1881ms in this case). About half of that was in the Refactor actions
We are aware of this. However the problem is an architectural problem in Platform/UI which I discussed with Nick at EclipseCon. Since we have global menu entries for all our actions we have to retarget them and initialize the right enablement state. Otherwise short cuts will not work correctly or the enablement state will not be correct if the global menu pops down. We will look into improving this however there are no low hanging fruits ;-)
Tobias, as discussed we should avoid that the refactoring actions load the refactorings/processor to determine their enablement state. Can you please add the improvement this will give to this PR. We can then decide if it is worth doing anything else.
Profiling shows that a lot of time is spent to load the refactoring classes for availability checking. Additionally, the empty IStructuredSelection on startup could be handled more efficiently. Extracted availability checking of all refactorings to a single class, implemented early pruning on the selections to avoid java model access. The performance gain is significant: On average, the refactor action group needs 500ms less time to initialize itself. Avoiding eager class-loading seems to be an easy way to shorten the startup time in this case.
My profile of opening the JavaPerspective showed the following (I had already touched the plug-in by selecting the preference page while in the resource perspective). Of the 3.456 seconds it took to open the Java Perspective 1.767 (51%) of them were taken in the PackageExplorerActionGroup constructor. Refactor was about a quarter of this time. I will attack the profilers trace
Created attachment 18807 [details] Trace of opening the Java Perspective
Created attachment 18808 [details] Trace with content type corrected
Tobias, as discussed we should create a trace to further understand what classes are loaded during package explorer startup. May be there are some additional low hanging fruits.
Avoided bundle loading of LTK Core/UI Implemented cut to avoid eager class loading during byte code verification Fixed > 20050414
What sort of performance gain does this give us?
On my machine P4 3Ghz 768 MB I measured the following for the package explorer open test, on clean installations and fresh workspaces: 3.0.2: 1.75s CPU Time I20050413-0910: 900ms CPU Time I am not sure why these numbers are not reflected in the performance tests (this has perhaps something to do with the downgrading of the windows test machines?)
