Groovy 1.6 startup time woes

[hdockter]

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. I would be more than happy to  
trade Groovy startup time against Groovy execution time for Gradle.  
Are there any plans to achieve an improved startup time for future  
versions of Groovy? 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.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

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