7 Dec 00:48
Re: [groovy-user] What do you want: fast compiler and slow program or slow compiler and fast program?
On Sun, Dec 6, 2009 at 4:54 AM, Jochen Theodorou <blackdrag-BA+cFGlbTmA@public.gmane.org> wrote:
Please correct me when I'm wrong. In my experience there is a startup time with Groovy and an initialization time. When I did some benchmarking even 2 years ago, firing up a hello world application in Groovy was fast. But for code that did real stuff the story was already different. There seems to be a significant first-pass penalty. So let's say for getting a list of all task of your gradle build the hick-up was quite noticeable. And that got worse with later groovy versions. Still better than with the other JVM languages like JRuby, but it is a problem. It would be fantastic to have switches for different kind of optimizations. I'm very happy that you are targeting this issue. I think one-time jobs in whatever form are an important use cases for the Groovy ecosystem.
BTW: Mark Reynolds was talking at Devoxx about how JDK 7 and the new module system will make classloading faster.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
Martin C. Martin schrieb:How much of this is JVM startup time? Even if Jochen worked magic, it may still be too slow.
Randall J. Parr wrote:
invoking the Groovy scripts 100's of times just kills the performance because Groovy takes so much longer to startup.
Groovy used to have a startup time that is nearly only VM startup time, but today it is like VM startup time multiplied with two due to the dgm$ helper classes, which are good for the overall performance, but for startup time they are quite bad.
Please correct me when I'm wrong. In my experience there is a startup time with Groovy and an initialization time. When I did some benchmarking even 2 years ago, firing up a hello world application in Groovy was fast. But for code that did real stuff the story was already different. There seems to be a significant first-pass penalty. So let's say for getting a list of all task of your gradle build the hick-up was quite noticeable. And that got worse with later groovy versions. Still better than with the other JVM languages like JRuby, but it is a problem. It would be fantastic to have switches for different kind of optimizations. I'm very happy that you are targeting this issue. I think one-time jobs in whatever form are an important use cases for the Groovy ecosystem.
BTW: Mark Reynolds was talking at Devoxx about how JDK 7 and the new module system will make classloading faster.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
One of the things I wanted to look into to is to use an database like structure for the dgm stuff instead of DefaultGroovyMethods or the dgm$ helpers directly, avoiding loading so many classes. This will move class verification times to the places the classes are actually needed, which means for most that they are never even loaded. Another startup time factor was the MetaClass creation stuff, but Alex did here already quite a job to reduce this noise.
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
RSS Feed