Community
Participate
Working Groups
We have compared startup performance of Eclipse M8 versus Eclipse 2.1.3 (empty workspace, cold rebooted machine). You can see the results here: http://wsperf2.torolab.ibm.com:9080/StudioPerf/servlet/CompareTests2? testid=3040849&testid=3040955. This shows a regression of 31% (19.2s versus 14.7s). We have not yet determined if this is a one-time cost or one that worsens with added plug-ins or more complex scenarios. Do your startup measurements show a similar regression?
Created attachment 10077 [details] Table of results generated by Gary Karasiuk.
Created attachment 11227 [details] Stats for M9 versus 213 (starting from rebooted machine)
Created attachment 11228 [details] Stats for M9 versus 213 (warm start)
The startup regression is now 18% for M9, down from 31% for M8.
Good improvement in M9, but we still have a performance regression here and the downstream product team are quite concerned about this one. Is further work expected for RC2?
FYI... Gary is re-running RC1 against V213. I'm especially interested in the increase in the number of active plug-ins for his scenario (opening the Java perspective on an empty workspace). To see what I mean, see the attached table. Test1 is V213. Nothing surprising there, it shows org.apache.xerces, org.eclipse.core.boot, and org.eclipse.swt were loaded in V213 but no longer in M9 (makes sense because of the restructuring -- not sure about swt (?)). Test2 is M9. A number of these are again attributed to restructuring and probably are a wash. But there are a few entries that seem out of place and are particularly expensive, e.g., update.configurator. I think there has been work in this area post-M9 that may help. This data was generated using the Runtime Spy / Core Tools. I will update this bug report with another table once Gary's runs are done. In the meantime, it might be prudent to run your own tests and see if the newly loaded plug-ins could be deferred.
Created attachment 11399 [details] Comparison of loaded plug-ins V213 versus M9
Created attachment 11401 [details] RC1 versus V213 (warm start)
Created attachment 11402 [details] RC1 versus V213 (rebooted)
Note an increase in read I/O and higher CPU usage in both warm and rebooted runs. This may be related to added plug-in / class loading. I will post the plug-in comparision shortly.
Created attachment 11409 [details] Comparison of loaded plug-ins V213 versus RC1
Created attachment 11410 [details] Plug-in net startup comparison, RC1 versus V213 (warm) Core runtime seems to account for a large portion of the regression.
Created attachment 12041 [details] RC2 versus V213 (warm and rebooted)
Should we expect further improvement in RC3? If so, please target this bug for RC3. If not, should it be marked resolved or targeted for 3.0.1?
Note: Same VM was used in both 2.1.3 and RC2 scenarios no additional command line args to alter VM defaults All times in milliseconds to launch eclipse, each case run 10 times description of setup for each testcase below. Case 1: Opening an empty workspace, only the resource perspective is open 2.1.3 Average = 2494.6 Std Dev = 19.15 RC2 Average = 2814 Std Dev = 37.7 RC2 is 12.8% slower Case 2: Import SWT, Package Explorer is active part (no editors open) 2.1.3 Average = 4065.7 StdDev 16.94 RC2 Average = 3733.2 StdDev 34.56 RC2 is 9% faster Case 3: Create a Java Project, Create 10 classes each with 100 errors, Resource Perspective is active, No editors 2.1.3 Average 3175.7 StdDev 16.19 RC2 Average 2886.2 StdDev 42.50 RC2 is 9% faster Case 4: Import src.zip from JDK 1.4 into 1 project, Package Explorer is active part (no editors opened) 2.1.3 Average 6453.2 StdDev 15.73 RC2 Average 4016.78 StdDev 18.57 RC2 is 38% faster From the time this defect was originally opened there has been a significant improvement but we are not yet showing across the board improvements in performance. There will be ongoing work post 3.0 to make this better.
