| Eclipse startup time too long [message #986965] |
Thu, 22 November 2012 15:17  |
 Jason Keltz
Messages: 3
Registered: November 2012 |
Junior Member |
|
|
Hi.
On our departments systems, many users are using Eclipse, and we have a fair number of plugins. The Eclipse 4.2/plugins directory has 870 plugins. Startup when a user does not have an existing .eclipse directory takes over 30 seconds, which seems very long in comparison to other large software packages. During this time, I see that the system stats all of the 870 plugins in the plugins directory. Interestingly enough, I tried to load the entire Eclipse installation into a ramdisk, and yet startup time was the same!
Okay - I guess we can handle this one time setup if the user doesn't have to experience it every single time they use Eclipse. However, frequently, our students are having "in lab" tests where they use, you guessed it - Eclipse! These tests always start the user off with an empty home directory. Now, over 100 students startup Eclipse at approximately the same time, and they all need to stat over 870 plugins.... they sit there waiting, and waiting, and waiting.... and they have to do this for each test. Eclipse is on an NFS share, but in all fairness, localizing it doesn't really help significantly either. I mean, if placing the whole installation on a ramdisk doesn't make initialization quicker, localizing it isn't going to do much either.
I can see that reducing the number of plugins in the Eclipse folder significantly reduces the startup time, but we have so many different users with different development requirements. We could have different versions of Eclipse installed, but even the Java developer one has over 400 plugins by default. Stat time on that takes significantly less though.
Surely there is a way to improve the startup time?
Jason.
|
|
|
| Re: Eclipse startup time too long [message #987138 is a reply to message #986965] |
Fri, 23 November 2012 17:46  |
Eclipse User |
|
|
|
|
The default configuration of Eclipse includes the old update reconciler which scans and adds any bundles in the plugins/ directory. You can disable this plugin with the following system property org.eclipse.update.reconcile=false.
|
|
|
|
| Re: Eclipse startup time too long [message #987170 is a reply to message #987148] |
Fri, 23 November 2012 23:11 |
| Eclipse User |
|
|
|
Jason Keltz wrote on Fri, 23 November 2012 14:45I then found some more information on the web, and looked at eclipse/configuration/config.ini where I found as the first line already:
org.eclipse.update.reconcile=false
That's interesting -- I didn't know that option was disabled in the IDE.
I don't think the number of stat()s necessarily means anything: the file metadata should be cached by the OS (well, maybe not across NFS?).
There's a few things I can think of:
- Create a file called .options containing "org.eclipse.osgi/debug/bundleTime=true", and then run with "-debug .options". This will provide the time taken to activate each bundle.
- Try using jvisualvm to profile the startup time: it would be good to see where the time is going
|
|
|
| Re: Eclipse startup time too long [message #987468 is a reply to message #986965] |
Mon, 26 November 2012 17:48 |
Jason Keltz
Messages: 3
Registered: November 2012 |
Junior Member |
|
|
Hi Brian.
The previous "performance test" that I did on Friday was done on a local copy of Eclipse so that NFS would not come into question. The truth is, the results between running Eclipse from a local copy and from an NFS copy are almost identical anyway.
I repeated the test today with a bit more information. I've also included the debug log from each run:
[1.txt] Start Eclipse on a rebooted system, with no .eclipse and no workspace directory:
Time to get to "Select a workspace": 27 seconds
Time after hitting OK before Eclipse is finished: 13 seconds
Therefore, the total time to start Eclipse from fresh is 40 seconds!
[2.txt] Re-start Eclipse after exiting:
Time to get to "Select a workspace": 3 seconds
Time after hitting OK before Eclipse is finished: 7 seconds
[3.txt] Re-start Eclipse after removing .eclipse:
Time to get to "Select a workspace": 9 seconds
Time after hitting OK before Eclipse is finished: 6 seconds
[4.txt] Re-start Eclipse after removing workspace directory:
Time to get to "Select a workspace": 2 seconds
Time after hitting OK before Eclipse is finished: 6 seconds
That being said, in our "test mode", all the machines are rebooted, and students start with an empty directory, so at best, they are looking at a 40 second delay. We obviously can't rely on Eclipse being cached on a machine that has just been rebooted unless there's an easy way for me to make that happen as part of the boot sequence. That delay is sometimes even more as well (up to a minute!). This is what I'd to be able to improve upon if possible.
Right after doing this testing, I repeated a few runs of the test from Friday:
% rm -rf ~jas/.eclipse ;time /local/eclipse-4.2/eclipse -initialize
15.140u 0.730s 0:25.34 62.6% 0+0k 172464+15544io 732pf+0w
% rm -rf ~jas/.eclipse ; time /local/eclipse-4.2/eclipse -initialize
14.645u 7.581s 0:15.32 145.0% 0+0k 0+15536io 0pf+0w
% rm -rf ~jas/.eclipse ; time /local/eclipse-4.2/eclipse -initialize
14.665u 4.995s 0:15.87 123.8% 0+0k 832+15536io 7pf+0w
% rm -rf ~jas/.eclipse ; time /local/eclipse-4.2/eclipse -initialize
14.952u 0.765s 0:17.28 90.9% 0+0k 768+15536io 1pf+0w
Followed immediately by running without the rm:
% time /local/eclipse-4.2/eclipse -initialize
3.311u 0.131s 0:07.03 48.9% 0+0k 0+64io 0pf+0w
% time /local/eclipse-4.2/eclipse -initialize
3.288u 0.122s 0:06.85 49.6% 0+0k 0+64io 0pf+0w
% time /local/eclipse-4.2/eclipse -initialize
3.110u 0.140s 0:06.77 48.0% 0+0k 0+64io 0pf+0w
Followed by just running eclipse without "initialize"
(again, 2 seconds to "select a workspace".)
It would be nice if I could get Eclipse, even on a freshly rebooted machine started very quickly.
Jason.
Attachment: 1.txt
(Size: 12.52KB, Downloaded 270 times)-
Attachment: 2.txt
(Size: 11.46KB, Downloaded 315 times) -
Attachment: 3.txt
(Size: 12.44KB, Downloaded 336 times) -
Attachment: 4.txt
(Size: 11.53KB, Downloaded 344 times)
|
|
|
Powered by
FUDForum. Page generated in 0.03155 seconds
] 
Search
Help
Register
Login
Home
