Re: groovy is slow

by Paul King :: Rate this Message:

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

« Return to Thread: groovy is slow