Community
Participate
Working Groups
I will attach a stack trace of the startup time of the commands support. Note that it is likely not actually this bad as the profiler causes some performance degredation. I started a workbench with platform-ui loaded from HEAD with no editors open and only the resource perspective (default settings) open.
Created attachment 10537 [details] Html stack trace
Doug, I would like to close this if we can claim improvement and that the current support is good. Kevin offered to get some performance numbers, adding him to the CC
No work has been done on this bug, to my knowledge. Pascal said he would look a bit at ways of improving this, but I believe (last I heard) that the results were somewhat inconclusive.
The only thing I've done, with Doug's help, was to turn off the update of the command registry on startup. Unfortunately this did not provide an improvement that worth it because still the registry is read and the zillions of objects created.
Summary for this defect report is misleading. (Only under profiler did command startup ever take 3 seconds). On my thinkpad setting up the commands took a few hundred milliseconds. (aprox 300) Looking into this code there are definite opportunities for improving the performance.(like using core's optimizatios of caching the registry derived data and avoiding re-reading the registry if the eclipse install has not changed. Removing this time would save about 1/3 of the time to setup commands and would scale better.
On Kevin's recommendation, this is being deferred from 3.0.
+1 (but bumping priority so it does not get lost when we start 3.1 work)
John: This the start-up performance bug I was speaking about.
I have made improvements in this area related to the size of objects created and the number of events fired. Still to consider is the possibility of serializing the state on shutdown, rather than going through the registry each time.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
My recent profiling of startup has not found any significant bottleneck in commands initialization - I think your elimination of those unnecessary events has made a big difference. I think you can close this - I'll be sure to open a new bug if I find any more problems ;)
Never one to turn down an offer to close bugs.... Thanks for all your help with this John....
Doug can you give me some stats that I can post on our performance page please (i.e. percent space or time improvements)?
I don't know if this is an apples to apples comparison because the code has changed so much. I tried the same test case (platform-ui from HEAD, resource perspective, no editors open). WorkbenchCommandSupport.<init> now takes 0.33% of total startup time, while it shows 9.89% of startup in the trace attached to this bug. However, the trace shows most of the time in reading the command registry from disk. This now appears to happen in BindingService.readRegistryAndPreferences, which takes 2.3% of total startup time in I20050331. My reading is that total impact on startup time is probably about 5-7%, between the original trace (roughly 3.0), and 3.1 M6.
