Home » Eclipse Projects » Eclipse Platform » Eclipse startup peformance
| |
| Re: Eclipse startup peformance [message #336737 is a reply to message #336710] |
Tue, 30 June 2009 06:40   |
 Nikita Lipsky
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Eclipse startup performance relates to general Java startup performance
and there is nothing specific to Eclipse in it.
I have not direct links to articles about it, however I have first-hand
experience of improving it, especially for Eclipse. So I have some
comments for the subject.
Actually, there are two startup times: so called "warm" startup time that
is startup time when you say closes and opens Eclipse again (f.i. by
switching workspace) and the most annoying "cold" startup time, when you
start Eclipse just after OS restart.
Cold startup time is 10 time worse than warm startup so the first idea to
improve startup performance is to make "cold" startup warmer by touching
necessary code before it actual starts. That is exactly what Java Quick
Starter does (JQS -- http://java.com/en/download/help/quickstarter.xml).
However JQS touches only JVM related stuff but Eclipse now is much bigger
than JVM itself, thus JQS does not help much for improving Eclipse cold
startup performance (10-15% AFAIK). So what can be done by Eclipse
community in this subject is to include something like JQS tool to Eclipse
packages that will be touching Eclipse code before it starts. Or another
way is to negotiate with Sun to add to JQS some customizing feature that
will allow to configure JQS to touch Eclipse also.
JQS is good but the trick anyway. If we talk about actual startup
performance improving I have a couple of words about this too.
Cold startup is all about reading data and code from the disk (hard
drive).
When we did our Eclipse RCP solution
( http://www.excelsior-usa.com/protect-eclipse-rcp-application s.html), once
we have noticed that even just reading the bytecode from the disk without
any verification and of course without any Just-In-Time compilation has
big-big portion in the whole startup time. So once we got rid from the
bytecode reading at startup, that is possible when we talk about native
compilation, we had improved the startup time greatly. Yes, we did get rid
from the bytecode reading, but instead we must read native code (compiled
from bytecode before start) from the disk that is actually bigger than
bytecode. So you may ask how we deal with this. The key idea to improve
cold startup time is to reorder code and data segments in the order of
their accessing at startup
(http://www.excelsior-usa.com/doc/jet650/jetw014.html#0344). So once you
have startup profile you may easily do it. The technique is applicable not
only to JVMs with AOT but to conventional JVMs too: we had a consultancy
project with one well-known company that has big Java project (comparable
to Eclipse in size) where we were able to improve startup time simply by
reziping their jars in the order of class accessing at startup. So it is
idea number two for Eclipse community in the subject (the first one was
JQS customizing :) )
Warm startup time is sum of , yes, bytecode reading, bytecode verification
and bytecode interpretation + bytecode just-in-time compilation.
Code and data reordering works great for bytecode reading for the warm
startup too. As to bytecode verification, split verifier
(https://jdk.dev.java.net/verifier.html) works great here for conventional
JVMs. So the idea number three is to compile the whole Eclipse with Java
SE 6 (and move to Java 6 then as a result). Or just have additional
Eclipse packages that are compiled with Java 6 for startup improving. As
to JVMs with AOT -- the bytecode verification is done at AOT compilation
stage so it has zero overhead in startup time here. Regarding bytecode
interpretation, yes, the only way to improve this is to compile bytecode
to native code ahead of time :). As a result warm startup time of natively
compiled Eclipse may be two times better -- you may download such Eclipse
from here --
http://www.excelsior-usa.com/download/jet/rcp/eclipse-classi c-win32 . Cold
startup is also better (we have noticed 25% improvement) but thanks to
code&data reordering.
--Nikita
|
|
|
| Re: Eclipse startup peformance [message #336739 is a reply to message #336737] |
Tue, 30 June 2009 07:14 |
Nikita Lipsky
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
I have just another comment for the subject.
Actually, Eclipse has built-in feature for improving startup time: it caches
several files that it deals at startup in configuration directory. However
it seems that Eclipse does not check cache consistency properly. As a result
any side-effect of improper use of inconsistent cache may appear. So the
first workaround when someone notices a glitch in Eclipse is to cleanup the
cache :). So we do not recommend to use this feature now and we even turned
it off for our solution. However cache consistency checking would be another
way of honest improving startup performance :).
"Nikita Lipsky" <nlipsky@excelsior-usa.com> wrote in message
news:457ae80f86860d2aac114c83c1ade11c$1@www.eclipse.org...
> Eclipse startup performance relates to general Java startup performance
> and there is nothing specific to Eclipse in it.
> I have not direct links to articles about it, however I have first-hand
> experience of improving it, especially for Eclipse. So I have some
> comments for the subject.
>
> Actually, there are two startup times: so called "warm" startup time that
> is startup time when you say closes and opens Eclipse again (f.i. by
> switching workspace) and the most annoying "cold" startup time, when you
> start Eclipse just after OS restart.
> Cold startup time is 10 time worse than warm startup so the first idea to
> improve startup performance is to make "cold" startup warmer by touching
> necessary code before it actual starts. That is exactly what Java Quick
> Starter does (JQS -- http://java.com/en/download/help/quickstarter.xml).
> However JQS touches only JVM related stuff but Eclipse now is much bigger
> than JVM itself, thus JQS does not help much for improving Eclipse cold
> startup performance (10-15% AFAIK). So what can be done by Eclipse
> community in this subject is to include something like JQS tool to Eclipse
> packages that will be touching Eclipse code before it starts. Or another
> way is to negotiate with Sun to add to JQS some customizing feature that
> will allow to configure JQS to touch Eclipse also.
> JQS is good but the trick anyway. If we talk about actual startup
> performance improving I have a couple of words about this too.
> Cold startup is all about reading data and code from the disk (hard
> drive). When we did our Eclipse RCP solution
> ( http://www.excelsior-usa.com/protect-eclipse-rcp-application s.html), once
> we have noticed that even just reading the bytecode from the disk without
> any verification and of course without any Just-In-Time compilation has
> big-big portion in the whole startup time. So once we got rid from the
> bytecode reading at startup, that is possible when we talk about native
> compilation, we had improved the startup time greatly. Yes, we did get rid
> from the bytecode reading, but instead we must read native code (compiled
> from bytecode before start) from the disk that is actually bigger than
> bytecode. So you may ask how we deal with this. The key idea to improve
> cold startup time is to reorder code and data segments in the order of
> their accessing at startup
> (http://www.excelsior-usa.com/doc/jet650/jetw014.html#0344). So once you
> have startup profile you may easily do it. The technique is applicable not
> only to JVMs with AOT but to conventional JVMs too: we had a consultancy
> project with one well-known company that has big Java project (comparable
> to Eclipse in size) where we were able to improve startup time simply by
> reziping their jars in the order of class accessing at startup. So it is
> idea number two for Eclipse community in the subject (the first one was
> JQS customizing :) )
> Warm startup time is sum of , yes, bytecode reading, bytecode verification
> and bytecode interpretation + bytecode just-in-time compilation. Code and
> data reordering works great for bytecode reading for the warm startup too.
> As to bytecode verification, split verifier
> (https://jdk.dev.java.net/verifier.html) works great here for conventional
> JVMs. So the idea number three is to compile the whole Eclipse with Java
> SE 6 (and move to Java 6 then as a result). Or just have additional
> Eclipse packages that are compiled with Java 6 for startup improving. As
> to JVMs with AOT -- the bytecode verification is done at AOT compilation
> stage so it has zero overhead in startup time here. Regarding bytecode
> interpretation, yes, the only way to improve this is to compile bytecode
> to native code ahead of time :). As a result warm startup time of natively
> compiled Eclipse may be two times better -- you may download such Eclipse
> from here --
> http://www.excelsior-usa.com/download/jet/rcp/eclipse-classi c-win32 . Cold
> startup is also better (we have noticed 25% improvement) but thanks to
> code&data reordering.
> --Nikita
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 15:07:58 GMT 2024
Powered by FUDForum. Page generated in 0.02051 seconds |
] 
Search
Help
Register
Login
Home
