« Return to Thread: Groovy 1.6 startup time woes
Re: Groovy 1.6 startup time woes
by Jochen Theodorou
::
Rate this Message:
sorry for the delay Hans
Hans Dockter schrieb:
> We have just updated Gradle to internally use Groovy 1.6. There are a
> number of reasons why we did this. One was that some of our users want
> to use 1.6 features in the build script.
>
> Unfortunately this has a big impact on the startup time of a Gradle
> build. It takes about 40 percent longer for a hello world build to
> execute. The Gradle build itself, with its large number of integration
> tests, takes now over 17 minutes compared to 12 minutes and 45 seconds
> with Groovy 1.5.6. I know that this is a trade off for the runtime
> performance improvement of Groovy 1.6. But I think there is a major
> usage scenario for Groovy, where the startup time is important and not
> so much the runtime performance.
to counter that reasonably we would have to know what exactly is causing
the high startup time. Factors are IMHO class loading, compilation, meta
class creation, general initialization of datastructures. For example if
most of the time is spend for class loading, then we have to either use
the new jdk 6 method to help the verifier to speed him up later, or to
reduce the amount of classes a normal hello world program requires. all
the call site stuff added a lot of classes, especially those hundreds of
classes that are intended to speed DGM up.
> I would be more than happy to trade
> Groovy startup time against Groovy execution time for Gradle.
maybe we can build an alternative startup mode, but for this we need
numbers.
> Are there
> any plans to achieve an improved startup time for future versions of
> Groovy?
atm not really
> Unfortunately startup time is usually not measured in all those
> benchmark comparisons between the different new JVM languages (I know
> that Groovy has still the lead in this field, but better is better). But
> for real life I think startup time is very important.
if you refer to the alioth shootout game (no real benchmark, a game),
then it should be noted, that startup time goes in there. But they
mainly have numeric stuff and here the time required through loading the
DGM stubs is less important compared to the speedup you gain from being
able to execute 1+1 at nearly native speed. So benchmarks or benchmark
games are usually not good to test that.
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Hans Dockter schrieb:
> We have just updated Gradle to internally use Groovy 1.6. There are a
> number of reasons why we did this. One was that some of our users want
> to use 1.6 features in the build script.
>
> Unfortunately this has a big impact on the startup time of a Gradle
> build. It takes about 40 percent longer for a hello world build to
> execute. The Gradle build itself, with its large number of integration
> tests, takes now over 17 minutes compared to 12 minutes and 45 seconds
> with Groovy 1.5.6. I know that this is a trade off for the runtime
> performance improvement of Groovy 1.6. But I think there is a major
> usage scenario for Groovy, where the startup time is important and not
> so much the runtime performance.
to counter that reasonably we would have to know what exactly is causing
the high startup time. Factors are IMHO class loading, compilation, meta
class creation, general initialization of datastructures. For example if
most of the time is spend for class loading, then we have to either use
the new jdk 6 method to help the verifier to speed him up later, or to
reduce the amount of classes a normal hello world program requires. all
the call site stuff added a lot of classes, especially those hundreds of
classes that are intended to speed DGM up.
> I would be more than happy to trade
> Groovy startup time against Groovy execution time for Gradle.
maybe we can build an alternative startup mode, but for this we need
numbers.
> Are there
> any plans to achieve an improved startup time for future versions of
> Groovy?
atm not really
> Unfortunately startup time is usually not measured in all those
> benchmark comparisons between the different new JVM languages (I know
> that Groovy has still the lead in this field, but better is better). But
> for real life I think startup time is very important.
if you refer to the alioth shootout game (no real benchmark, a game),
then it should be noted, that startup time goes in there. But they
mainly have numeric stuff and here the time required through loading the
DGM stubs is less important compared to the speedup you gain from being
able to execute 1+1 at nearly native speed. So benchmarks or benchmark
games are usually not good to test that.
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: Groovy 1.6 startup time woes
| Free embeddable forum powered by Nabble | Forum Help |
