« Return to Thread: groovy is slow
Re: groovy is slow
by Alexandru Popescu ☀
::
Rate this Message:
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
>
>
> 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
« Return to Thread: groovy is slow
| Free embeddable forum powered by Nabble | Forum Help |
