Re: groovy is slow

by Russel Winder-4 :: Rate this Message:

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: +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

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

http://xircles.codehaus.org/manage_email

« Return to Thread: groovy is slow