Two Laptop Bag
The moose likes Groovy and the fly likes Groovy Perforamance: A Little Disapointed Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Languages » Groovy
Bookmark "Groovy Perforamance: A Little Disapointed" Watch "Groovy Perforamance: A Little Disapointed" New topic

Groovy Perforamance: A Little Disapointed

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15302

First let me state that I understand Groovy (and scripting languages in general) are going to be slower than a more native counterpart. However, I thought that in groovy's case things would level out once the groovy scripts were compiled to bytecode. This doesn't seem to be the case.

Ubuntu 7.10
Java 1.6.0_03-b05
Groovy 1.5.4

I created a groovy script and a Java class to read a text file containing 10,000 lines of text that were all the same length. I then executed each 20 times.

I created a the following groovy script:

Running this as a groovy script I averaged about 791 ms. I compiled the script and ran it as bytecode and averaged about 604 ms.

I then created the following Java class.

Running this averages at about 336 ms. So in review:

groovy script: 791 ms
groovy bytecode: 604 ms
java: 336 ms

I have to say that I was more surprised that the difference between groovy script and groovy compiled wasn't more. But I was still disappointed at the difference between groovy compiled and java; nearly twice as slow running the compile groovy code. I realize benchmarks like this don't mean a whole lot. I did expect a different outcome though.

GenRocket - Experts at Building Test Data
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
Hm, well a factor of two or so doesn't sound bad really. There's a lot of discussion right now on the groovy-dev mailing list about strategies to improve performance in the future - it seems to be a primary focus right now. Groovy call stacks tend to be rather, um, baroque with all their mechanisms for dynamic overrides and whatnot, even with compiled bytecode. My understanding is 1.6 is supposed to have some significant improvements in that area, and 2.0 hopes for considerably more, simplifying call stacks considerably.

"I'm not back." - Bill Harding, Twister
Liz Ardu

Joined: Feb 20, 2008
Posts: 7
I took your 4 line script:

Put it in a file "test.groovy", groovyc'd it, and then decompiled the class file with JAD. Check out the result. Slightly more than your equivalent Java program.

Mark Herschberg

Joined: Dec 04, 2000
Posts: 6037
Good thinking Liz; that's some interesting results.

I'm a little surprised by this as well. Last week I asked Jeff Brown about Groovy performance. One interesting thing he noted was that because groovy isn't typesafe there are less checks on the variable, so it's faster in some aspects--although overall groovy is slower.

That said, a factor of 2 is usually my breakpoint for performance. By that I mean, if between technologies A and B, the former is easier to code or maintain, or has better support, etc. and comes at a a cost of a factor of 2 or less, I'll typically pick A. Usually the cost of additionally hardware in the next 2 years is outweighed by the reduced cost of code, and after 2 years the hardware only gets faster. Of course it depends a lot on your particular situation.

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15302

Thanks Liz. I assumed as much. I just didn't have the tool at my disposal. And good points Mark.
I agree. Here's the link:
subject: Groovy Perforamance: A Little Disapointed
It's not a secret anymore!