File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Groovy Perforamance: A Little Disapointed

 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Liz Ardu
Greenhorn
Posts: 7
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 6037
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

--Mark
 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Liz. I assumed as much. I just didn't have the tool at my disposal. And good points Mark.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic