Groovy "fast mode"

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Groovy "fast mode"

Thom Nichols
Hi,

I wanted to revisit the topic of a 'fast mode' as was touched on in this thread:
http://www.nabble.com/Groovy-Performance-Question-tf2227482.html

Has this been discussed more in-depth somewhere else?  Here are my
questions and thoughts:

1.  Might it cause compatibility issues with Groovy code that is
explicitly non-fast-mode?  i.e. if I wanted to run my code in fast
mode, could I call library code that was non-fast-mode?  This makes me
think we would it to be a class level annotation rather than a runtime
switch.

2.  It _does_ seem like a bit of a band-aid, and likely something that
would only exist until the normal Groovy performance improved to an
acceptable level, no?

3.  I think it would be a big draw to current Java developers who want
to start using Groovy but don't want a huge performance loss.
Obviously they'd be missing out on features, psychology principles
suggest that people would rather retain something they already have
(performance) rather than gain something they don't yet have (some
dynamic features).

The only real concern I have is that if it appears to to cause
compatibility problems it could look like a kludge and cause a poor
perception of the language...   Is anyone else thinking along these
same lines?

Thanks!
-Tom

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Groovy "fast mode"

Guillaume Laforge
Administrator
Thinking about some "fast mode" is somewhat of a wild idea at the moment.

And it's not a top priority to think more about it right now.

The performance of Groovy is somewhat lower than the one of Java, but
so far, we haven't really come across a situation where we couldn't
speed-up Java+Groovy applications (by rewriting a few lines in Java in
helper classes or things like that).

So to answer your questions more precisely:

1) It's possible that there could be some uncompatible semantics
difference of a code in fast mode and a non-fast mode code, since a
solution could be to bypass the dymanic features offered by Groovy.

2) I think what Jochen had in mind would be that you could choose
between standard Java compile-time method dispatch and Groovy dynamic
runtime dispatch. And the consequence of this is that the performance
should be that of raw Java. Hence why Jochen called it "fast mode".

3) Very good remark. Anyway, so far, not that much optimization effort
has been done on increasing Groovy's performance. And in fact, it's
not that bad already. But the internal refactorings we're working on
at the moment should help to improve that performance a bit, and we'll
continue to do so as much as possible.

On 9/10/06, Tom Nichols <[hidden email]> wrote:

> Hi,
>
> I wanted to revisit the topic of a 'fast mode' as was touched on in this thread:
> http://www.nabble.com/Groovy-Performance-Question-tf2227482.html
>
> Has this been discussed more in-depth somewhere else?  Here are my
> questions and thoughts:
>
> 1.  Might it cause compatibility issues with Groovy code that is
> explicitly non-fast-mode?  i.e. if I wanted to run my code in fast
> mode, could I call library code that was non-fast-mode?  This makes me
> think we would it to be a class level annotation rather than a runtime
> switch.
>
> 2.  It _does_ seem like a bit of a band-aid, and likely something that
> would only exist until the normal Groovy performance improved to an
> acceptable level, no?
>
> 3.  I think it would be a big draw to current Java developers who want
> to start using Groovy but don't want a huge performance loss.
> Obviously they'd be missing out on features, psychology principles
> suggest that people would rather retain something they already have
> (performance) rather than gain something they don't yet have (some
> dynamic features).
>
> The only real concern I have is that if it appears to to cause
> compatibility problems it could look like a kludge and cause a poor
> perception of the language...   Is anyone else thinking along these
> same lines?
>
> Thanks!
> -Tom
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Groovy "fast mode"

Thom Nichols
Thanks for the clarification.  I agree, the best solution is that
performance is good enough to not warrant a 'fast mode' at all, but I
was just wondering "what if."  I'm sure we'll cross that bridge when
we get there.

Thanks.

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

    http://xircles.codehaus.org/manage_email