groovy is slow

[fangzx]

I have read this article 'Why is Groovy so slow?':
http://www.jroller.com/rants/entry/why_is_groovy_so_slow

I planed to use Groovy in my new project based on JBoss Seam, but now I must wait.
Can anyone give me some advice?

[glaforge]

It depends so much on what you're doing with Groovy.
Try Groovy with a small prototype of what you want to do with it,
benchmark it, also benchmark it against other tools / languages you'd
want to use, and see the results for yourself.
Inside a web application, you'll probably wait longer for the records
to come back from the database, than for the execution times of your
Groovy code.
Micro-benchmarks such as the one you pointed isn't really relevant to
99% of the use cases you'd want to use Groovy for.
So if you're solely basing your choice on a randomly found blog post,
I'm not sure you'll ever find the right choice for your own scenario
of usage.

Nonetheless, improving the performance is a key concern of ours, and
it's definitely something we're currently working on, to make sure
Groovy is the fastest dynamic language on the JVM.

Guillaume


On Dec 26, 2007 2:42 PM, fangzx <fangzhouxing@...> wrote:

>
> I have read this article 'Why is Groovy so slow?':
> http://www.jroller.com/rants/entry/why_is_groovy_so_slow
>
> I planed to use Groovy in my new project based on JBoss Seam, but now I must
> wait.
> Can anyone give me some advice?
>
>
> --
> View this message in context: http://www.nabble.com/groovy-is-slow-tp14502299p14502299.html
> Sent from the groovy - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

    http://xircles.codehaus.org/manage_email

[Smith, Jason, CTR, OASD(HA)/TMA]

Go ahead and try Groovy in your new project.  At the very worst, you
will have to port everything you did to Java, which is easy enough, and
not likely to happen.  At the best, you will find that most everything
you do can be written in Groovy and be performant too.

How is that possible?

Most of the code that actually runs is already written in Java!  You are
using JBoss.  Big honkin application.  Lots of functionality.  Just
about everything you will do in Groovy is going to be a method call into
some JBoss code.  Most of your time is spent in the JBoss code, not in
the overhead to call a single method.

If you run into a piece of code that needs raw performance (i.e. - a
binary tree, finding prime numbers, or God forbid, needlessly iterating
a counter a million times), by all means, do that in Java.  And if you
need a binary tree, use a TreeMap.  :-)

Visual Basic was an interpreted language through version 4, and despite
it's rather glaring design flaws and the limited hardware of the day, it
became wildly popular (because most of the "hard stuff" was written in
C++).  It became popular because it made things so much easier.  'Nuff
said.


Jason Smith
 
-----Original Message-----
From: fangzx [mailto:fangzhouxing@...]
Sent: Wednesday, December 26, 2007 6:42 AM
To: user@...
Subject: [groovy-user] groovy is slow


I have read this article 'Why is Groovy so slow?':
http://www.jroller.com/rants/entry/why_is_groovy_so_slow

I planed to use Groovy in my new project based on JBoss Seam, but now I
must wait.
Can anyone give me some advice?



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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Wed, 2007-12-26 at 05:42 -0800, fangzx wrote:
> I have read this article 'Why is Groovy so slow?':
> http://www.jroller.com/rants/entry/why_is_groovy_so_slow
>
> I planed to use Groovy in my new project based on JBoss Seam, but now I must
> wait.

Why?

The article is 4 months old and we have had new releases of Groovy since
then -- with a lot of emhasis on increasing performance.

The problem with the Web is that there is so much data and so little
real information.  You see an article and have absolutely no idea if it
is saying ahything useful or is just FUD.  In this case the article had
something to say in 2007-09, it is now 2007-12 and a lot of Alex's time
has been spent ripping out the slow stuff.

> Can anyone give me some advice?

Try it for yourself before you make any decisions.  Find the metrics
that matter to your application.  Do not use someone else's micro
benchmarks that have no relevance to you use, your algorithms and your
context.  If Groovy is too slow for you, your applications, in your
context then you can't use it.  But tell us about the problem you come
across.

Most people I know you listen to the "it's too slow FUD" who then try it
anyway find that Groovy is fast enough for their use, and their
development times plummet.

But most of all make your own decision on your own data -- don't be
bullied into a position by others.

(This is not just a Groovy issue, it also applies to C, C++, Fortran,
Python, Ruby, Scala, Prolog, Lisp, . . .  )

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]


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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

fangzx schrieb:
> I have read this article 'Why is Groovy so slow?':
> http://www.jroller.com/rants/entry/why_is_groovy_so_slow
>
> I planed to use Groovy in my new project based on JBoss Seam, but now I must
> wait.
> Can anyone give me some advice?

Russel basically answered to this very good,I just want to add that the
conclusions in the blog are not right for the languageGroovy, they are
just right for the current implementation. We will spend much time in
the next year to get Groovy running much faster. Then a word to these
benchmarks...

The loop is a very good example for hotspots abilities to unroll a loop,
skip its execution and make mostly a jump instead. The resulting Groovy
code is much complexeratm, making it much more difficult for hotspot to
do its job. What we will try now is to make alternative paths in the
code depending on when a custom  MOP is active or not. I very much
believe, that when this is implemented, the the code will be not only
much faster, but also much more compareable to Java.

Most possibly we won't able to be as fast Java, but I am sure we will be
able to get in regions where we will have an acceptable speed even for
things like that loop ;)

Oh.. one more thing... unlike normal Java code it makes much of a
difference if you use the server VM to execute Groovy sscripts

bye blackdrag

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

    http://xircles.codehaus.org/manage_email

[lloy0076-2]

Howdy,

> I planed to use Groovy in my new project based on JBoss Seam, but now I must
> wait.
> Can anyone give me some advice?

Groovy is also atrocious for doing the Naive recursive Fibonacci series,
but any computer science graduate or self taught programmer would
rewrite it into the faster, iterative form.

An advantage that Groovy has is that it is able to communicate directly
with a class or classes coded in Java itself. Therefore there should be
a number of clear cases where you can essentially replace slow Groovy
code with faster, more efficient Java code.

This doesn't stop the need for your own benchmarks and profilinhg. If
you benchmark or profile your own application which will have different
characteristics to the ones shown and find that a particular part is
going exceedingly slow, you can, in order from most important to least
important:

a) Determine whether the bottleneck would occur in "reality" and then
    determine if spending time optimising it is worth it

b) Determine if the algorithm you've chosen is the most efficient in the
    general sense

c) Determine if the algorithm you choose uncovers any current "flaws" in
    Groovy's implementation (1)

d) Write the algorithm in Java, benchmark it and then glue it back to
    your Groovy code

It's highly unlikely you'll need (e) if you're going to use the JBoss
Seam framework. I am going to assume that you're not going to write
"Breaking 256 AES/Rijndael" with the JBoss Seam framework and Groovy :)

Realistically, Groovy is unlikely to perform as badly as the benchmarks
you've posted state. They would be, I'd suggest, pathological cases and
whilst I used a pithy example in the previous paragraph, you're not
likely going to hit many pathological cases if any. Even if you do hit
one, you could simply farm it out to Java 6.0 but gain the benefits that
Groovy gives.

DSL

(1) EG:

Take this:

  int count = 0;
  int i = 0;
  for (i = 0; i++ < 10000; ) {
    ++count;
  }
  System.out.println("Count is " + count);

Clearly that can be optimised to:

  int count = 0;
  int i = 9999;
  count = 10000;
  System.out.println("Count is " + count);

I don't know if a non-human optimiser could do that (my hunch is that it
can), but clearly the second way is faster, and ridiculously faster for
Groovy because it avoids the "MOP" + "there are no primitives in Groovy"
issue.

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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Thu, 2007-12-27 at 15:09 +1030, David Lloyd wrote:
> Howdy,
>
> > I planed to use Groovy in my new project based on JBoss Seam, but now I must
> > wait.
> > Can anyone give me some advice?
>
> Groovy is also atrocious for doing the Naive recursive Fibonacci series,
> but any computer science graduate or self taught programmer would
> rewrite it into the faster, iterative form.

I think we have to go further:  Any and all programming languages are
truly appalling at implementing the naïve recursive expression of
factorial because the algorithm is O(n!)  Groovy is no worse than any
other language in this respect --  C, C++, Fortran and even Ruby :-) are
atrocious for this.

The only sane way of implementing factorial is using memoization.  It is
just a pity that so many books on introductory programming (even the
ones I write ! ) present factorial as an example recursive function
without dealing with this O(n!) issue.

> An advantage that Groovy has is that it is able to communicate directly
> with a class or classes coded in Java itself. Therefore there should be
> a number of clear cases where you can essentially replace slow Groovy
> code with faster, more efficient Java code.

You can use C or C++ for this as well with JNI :-)

> This doesn't stop the need for your own benchmarks and profilinhg. If
> you benchmark or profile your own application which will have different
> characteristics to the ones shown and find that a particular part is
> going exceedingly slow, you can, in order from most important to least
> important:
>
> a) Determine whether the bottleneck would occur in "reality" and then
>     determine if spending time optimising it is worth it

This is the single most important point that can be raised.  Do not
philosophize, do not guess, do not pretend.  Find out where the real
bottlenecks actually are in real executions of the program and then
focus optimization effort only on the bits that really matter, for real
in the real application.

> b) Determine if the algorithm you've chosen is the most efficient in the
>     general sense

OK, this is even more important than optimization :-)

Far too many people think O(n) algorithms are better than O(log n ).

> c) Determine if the algorithm you choose uncovers any current "flaws" in
>     Groovy's implementation (1)

Are there any ;-)

> d) Write the algorithm in Java, benchmark it and then glue it back to
>     your Groovy code

But only if you actually, really have to because there is an actual,
provably real bottleneck.
 

> It's highly unlikely you'll need (e) if you're going to use the JBoss
> Seam framework. I am going to assume that you're not going to write
> "Breaking 256 AES/Rijndael" with the JBoss Seam framework and Groovy :)
>
> Realistically, Groovy is unlikely to perform as badly as the benchmarks
> you've posted state. They would be, I'd suggest, pathological cases and
> whilst I used a pithy example in the previous paragraph, you're not
> likely going to hit many pathological cases if any. Even if you do hit
> one, you could simply farm it out to Java 6.0 but gain the benefits that
> Groovy gives.
>
> DSL
>
> (1) EG:
>
> Take this:
>
>   int count = 0;
>   int i = 0;
>   for (i = 0; i++ < 10000; ) {
>     ++count;
>   }
>   System.out.println("Count is " + count);
>
> Clearly that can be optimised to:
>
>   int count = 0;
>   int i = 9999;
>   count = 10000;
>   System.out.println("Count is " + count);
>
> I don't know if a non-human optimiser could do that (my hunch is that it
> can), but clearly the second way is faster, and ridiculously faster for
> Groovy because it avoids the "MOP" + "there are no primitives in Groovy"
> issue.

C, C++ and Fortran compilers can definitely find and eliminate code such
as this.  I suspect Java compilers should be able to.  I also suspect a
Groovy compiler has no chance.  Likewise Python and Ruby cannot.  As you
say the presence of a MOP means that you actually have no idea what the
program means so there is no chance of optimizing it.

OK, I over state the case a bit for this example as the variables are
declared to be int so Groovy might have a chance.  But Python and Ruby
don't as they have no static typing.
--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]


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

    http://xircles.codehaus.org/manage_email

[Daniel.Sun]

Jochen, I can not wait to try the next big version of Groovy :)

Daniel.Sun

Jochen Theodorou wrote:

fangzx schrieb:
> I have read this article 'Why is Groovy so slow?':
> http://www.jroller.com/rants/entry/why_is_groovy_so_slow
>
> I planed to use Groovy in my new project based on JBoss Seam, but now I must
> wait.
> Can anyone give me some advice?

Russel basically answered to this very good,I just want to add that the
conclusions in the blog are not right for the languageGroovy, they are
just right for the current implementation. We will spend much time in
the next year to get Groovy running much faster. Then a word to these
benchmarks...

The loop is a very good example for hotspots abilities to unroll a loop,
skip its execution and make mostly a jump instead. The resulting Groovy
code is much complexeratm, making it much more difficult for hotspot to
do its job. What we will try now is to make alternative paths in the
code depending on when a custom  MOP is active or not. I very much
believe, that when this is implemented, the the code will be not only
much faster, but also much more compareable to Java.

Most possibly we won't able to be as fast Java, but I am sure we will be
able to get in regions where we will have an acceptable speed even for
things like that loop ;)

Oh.. one more thing... unlike normal Java code it makes much of a
difference if you use the server VM to execute Groovy sscripts

bye blackdrag

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

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Russel Winder wrote:
> C, C++ and Fortran compilers can definitely find and eliminate code such
> as this.  I suspect Java compilers should be able to.  I also suspect a
> Groovy compiler has no chance.  Likewise Python and Ruby cannot.  As you
> say the presence of a MOP means that you actually have no idea what the
> program means so there is no chance of optimizing it.
>
> OK, I over state the case a bit for this example as the variables are
> declared to be int so Groovy might have a chance.  But Python and Ruby
> don't as they have no static typing.

Not true. An optimizing implementation of any of these languages could
easily discover that a given variable or variables are only ever used
with Integer objects and create an unboxed path of execution. This would
require Groovy to include a recompiler and to gather runtime profiling
information, as JRuby does (and of course, as the JVM itself does) but
it's entirely feasible.

Note JRuby does not do such optimization, but I'm going to look at that
in the next version. I will try to make whatever I write generic enough
to apply to other languages.

- Charlie

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

    http://xircles.codehaus.org/manage_email

[Paul King]

Until you run the same code a few seconds later after someone has opened the class and changed things causing all optimization assumptions to be invalid. No? (For the general case - obviously if you are willing to indicate somehow that you don't care about such cases, then much more can be done.)

Paul.

Charles Oliver Nutter-2 wrote:

Russel Winder wrote:
> C, C++ and Fortran compilers can definitely find and eliminate code such
> as this.  I suspect Java compilers should be able to.  I also suspect a
> Groovy compiler has no chance.  Likewise Python and Ruby cannot.  As you
> say the presence of a MOP means that you actually have no idea what the
> program means so there is no chance of optimizing it.
>
> OK, I over state the case a bit for this example as the variables are
> declared to be int so Groovy might have a chance.  But Python and Ruby
> don't as they have no static typing.

Not true. An optimizing implementation of any of these languages could
easily discover that a given variable or variables are only ever used
with Integer objects and create an unboxed path of execution. This would
require Groovy to include a recompiler and to gather runtime profiling
information, as JRuby does (and of course, as the JVM itself does) but
it's entirely feasible.

Note JRuby does not do such optimization, but I'm going to look at that
in the next version. I will try to make whatever I write generic enough
to apply to other languages.

- Charlie

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

    http://xircles.codehaus.org/manage_email

[Alexandru Popescu ☀]

On Dec 27, 2007 4:57 PM, Paul King <paulk@...> wrote:
>
>
> Until you run the same code a few seconds later after someone has opened the
> class and changed things causing all optimization assumptions to be invalid.
> No? (For the general case - obviously if you are willing to indicate somehow
> that you don't care about such cases, then much more can be done.)
>
> Paul.
>

Yep, this may happen. It is one of the risks you may run into when
optimizing for dynlangs. However, I still do think that this is
possibly an optimization for the majority of the cases.

./alex
--
.w( the_mindstorm )p.

>
>
> Charles Oliver Nutter-2 wrote:
> >
> > Russel Winder wrote:
> >> C, C++ and Fortran compilers can definitely find and eliminate code such
> >> as this.  I suspect Java compilers should be able to.  I also suspect a
> >> Groovy compiler has no chance.  Likewise Python and Ruby cannot.  As you
> >> say the presence of a MOP means that you actually have no idea what the
> >> program means so there is no chance of optimizing it.
> >>
> >> OK, I over state the case a bit for this example as the variables are
> >> declared to be int so Groovy might have a chance.  But Python and Ruby
> >> don't as they have no static typing.
> >
> > Not true. An optimizing implementation of any of these languages could
> > easily discover that a given variable or variables are only ever used
> > with Integer objects and create an unboxed path of execution. This would
> > require Groovy to include a recompiler and to gather runtime profiling
> > information, as JRuby does (and of course, as the JVM itself does) but
> > it's entirely feasible.
> >
> > Note JRuby does not do such optimization, but I'm going to look at that
> > in the next version. I will try to make whatever I write generic enough
> > to apply to other languages.
> >
> > - Charlie
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/groovy-is-slow-tp14502299p14513993.html
> Sent from the groovy - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

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

    http://xircles.codehaus.org/manage_email

[Randall Schulz]

On Thursday 27 December 2007 06:57, Paul King wrote:
> Until you run the same code a few seconds later after someone has
> opened the class and changed things causing all optimization
> assumptions to be invalid. No? (For the general case - obviously if
> you are willing to indicate somehow that you don't care about such
> cases, then much more can be done.)

The Sun JVM specializes and de-specializes for the purpose of method
in-lining.


> Paul.


Randall Schulz

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

    http://xircles.codehaus.org/manage_email

[Randall Schulz]

On Thursday 27 December 2007 03:10, Russel Winder wrote:
> ...
>
> I think we have to go further:  Any and all programming languages are
> truly appalling at implementing the naïve recursive expression of
> factorial because the algorithm is O(n!)

How is that?

Computing n! requires O(n) multiplications. The size of the result is
O(log(n!)). The cost of non-native multiplications scales with the log
of the magnitude of the number. If one uses a naive recursive
implementation and the execution machinery performs no tail recursion
elimination, the size of the stack at its maximum is O(n).

Nothing in computing factorial is O(n!). Not as long as you don't use
base 1 or successor notation to represent the number it manipulates.


> ...

Randall Schulz

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

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Paul King wrote:
>
> Until you run the same code a few seconds later after someone has opened the
> class and changed things causing all optimization assumptions to be invalid.
> No? (For the general case - obviously if you are willing to indicate somehow
> that you don't care about such cases, then much more can be done.)

Any such optimized path would also have a guard for when things don't go
as planned. So if you suddenly called a method that has an optimized
path for Integer with a String, the guard would fire and execute the
slower, less-specialized path. Or the guard could basically say "I was
wrong" and permanently fall back on the slow path.

The only cost of this is that the guard must always run before the code,
but that cost would largely pale in comparison to the gains from
unboxing Integer for even the smallest algorithms.

- Charlie

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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Thu, 2007-12-27 at 07:29 -0800, Randall R Schulz wrote:
> On Thursday 27 December 2007 03:10, Russel Winder wrote:
> > ...
> >
> > I think we have to go further:  Any and all programming languages are
> > truly appalling at implementing the naïve recursive expression of
> > factorial because the algorithm is O(n!)
>
> How is that?

Because I read one word and thought another.  Clearly using the word
factorial means my comments were complete and utter rubbish.  If
however, you substitute factorial with Fibonacci then my comments make
some sort of sense.

My only excuse is that I am working on some examples for a website
associated with a book (Python for Rookies, the book will appear early
Feb 2008 and the website should appear mid-Jan 2008), and it was a
public holiday.

> Computing n! requires O(n) multiplications. The size of the result is
> O(log(n!)). The cost of non-native multiplications scales with the log
> of the magnitude of the number. If one uses a naive recursive
> implementation and the execution machinery performs no tail recursion
> elimination, the size of the stack at its maximum is O(n).
>
> Nothing in computing factorial is O(n!). Not as long as you don't use
> base 1 or successor notation to represent the number it manipulates.

Agreed.

Memoization is still a good idea for factorial, though it is a better
idea for Fibonacci Series.

--
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: [phone]
41 Buckmaster Road,              f: [phone]
London SW11 1EN, UK.             m: [phone]


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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Alexandru Popescu ☀ schrieb:

> On Dec 27, 2007 4:57 PM, Paul King <paulk@...> wrote:
>>
>> Until you run the same code a few seconds later after someone has opened the
>> class and changed things causing all optimization assumptions to be invalid.
>> No? (For the general case - obviously if you are willing to indicate somehow
>> that you don't care about such cases, then much more can be done.)
>>
>> Paul.
>>
>
> Yep, this may happen. It is one of the risks you may run into when
> optimizing for dynlangs. However, I still do think that this is
> possibly an optimization for the majority of the cases.

it is no risc if you have a way to ensure that your optimization is
still right. The only risc is then that you have to make recompilations
and such. If you can'tensure that your optimization is valid, then it
will probably lead to false code and cause bugs... I don't think Charles
would suggest or implement an optimization that leads tofalse code.

bye blackdrag

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

    http://xircles.codehaus.org/manage_email

[Alexandru Popescu ☀]

On Dec 27, 2007 5:51 PM, Jochen Theodorou <blackdrag@...> wrote:

> Alexandru Popescu ☀ schrieb:
> > On Dec 27, 2007 4:57 PM, Paul King <paulk@...> wrote:
> >>
> >> Until you run the same code a few seconds later after someone has opened the
> >> class and changed things causing all optimization assumptions to be invalid.
> >> No? (For the general case - obviously if you are willing to indicate somehow
> >> that you don't care about such cases, then much more can be done.)
> >>
> >> Paul.
> >>
> >
> > Yep, this may happen. It is one of the risks you may run into when
> > optimizing for dynlangs. However, I still do think that this is
> > possibly an optimization for the majority of the cases.
>
> it is no risc if you have a way to ensure that your optimization is
> still right. The only risc is then that you have to make recompilations
> and such. If you can'tensure that your optimization is valid, then it
> will probably lead to false code and cause bugs... I don't think Charles
> would suggest or implement an optimization that leads tofalse code.
>

I haven't meant optimization leading to false code, but rather
optimization that immediately invalidated by the execution code (one
such example presented in this thread is specialization of a method
call, from a generic Object down to a primitive). The problem is that
you are normally deciding that this optimization should be applied
after a number of previous "observation" invocations. But then, the
app execution flow may change and so invalidate the optimized path
you've just created. All these optimization must use different guards
and fallback to the initial version when something is invalidating the
"optimization" conditions. For very special cases, this may finally
lead to worse performance. But most probably, for the majority of
cases the applying runtime optimization will pay a lot.

./alex
--
.w( the_mindstorm )p.


> bye blackdrag
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

[fangzx]

Thanks all for reply, and I learn a lot from it. I now stop waiting and began my first project of Groovy (based on JBoss Seam).

fangzx wrote:

I have read this article 'Why is Groovy so slow?':
http://www.jroller.com/rants/entry/why_is_groovy_so_slow

I planed to use Groovy in my new project based on JBoss Seam, but now I must wait.
Can anyone give me some advice?