67

What the performance of Groovy compared with Java?

oz123
  • 27,559
  • 27
  • 125
  • 187
user607498
  • 789
  • 1
  • 5
  • 4
  • 3
    Groovy is compiled to Java byte code & executed on a JVM. So I'd expect no difference. – David Victor Mar 08 '11 at 21:54
  • 9
    @David: That's not true. Different compilers are more efficient than others. Not every JVM language runs at the same speed. Also, Groovy is an interpreted language (though it might have a compiled mode). – Peter C Mar 08 '11 at 21:55
  • 1
    The question is not which compiler is more efficient than another ? The assumption in the question is in an environment where only the language is different - not the compiler/jvm - what are differences in performance. As commented I'd expect nothing significant - but you are correct that Groovy can be interpreted or compiled. – David Victor Mar 08 '11 at 22:02
  • Not sure why the question deserves a down vote ? – David Victor Mar 08 '11 at 22:03
  • @David: Well, that certainly influences their speed, doesn't it? And there are parts of Groovy (dynamic typing) that require slow techniques such as reflection for the implementation. – Peter C Mar 08 '11 at 22:05
  • It may affect performance (not "speed") - but I would not expect the differences to be significant. From Groovy In Action: "So far, when talking about Groovy and Java, we have compared the appear- ance of the source code. But the connection to Java is much stronger. Behind the scenes, all Groovy code runs inside the Java Virtual Machine (JVM) and is therefore bound to Java’s object model. Regardless of whether you write Groovy classes or scripts, they run as Java classes inside the JVM." – David Victor Mar 08 '11 at 22:08
  • @David: The differences **are** pretty significant. Just Google 'java vs groovy speed'. Here's one: http://stronglytypedblog.blogspot.com/2009/07/java-vs-scala-vs-groovy-performance.html – Peter C Mar 08 '11 at 22:24
  • Thank you. I stand corrected. I did not appreciate the significance. I also found this which asks more questions than provides answers. http://pegolon.wordpress.com/2008/01/24/quick-ruby-groovy-performance-comparison/ - its interesting that the question has no published benchmark to answer it ? I was misled by the Groovy spin which implies JVM-based languages offer similar performance. I will leave my original comment as is - as it helps to illustrate ignorance in this area (mine especially). :-) – David Victor Mar 08 '11 at 22:30
  • I did recently write some simple Groovy scripts which included timing figures which were no different to the equivalent Java code - but I was not hitting on "slow" Groovy features I guess. – David Victor Mar 08 '11 at 22:34
  • 1
    @David: I didn't realize they were that significant until I started Googling for benchmarks. Most statically-typed JVM languages are similar in speed, but the dynamic ones are slower. When Java 7 comes out with the `invokedynamic` instruction that may change however. – Peter C Mar 08 '11 at 22:36
  • 1
    @David: I'm not sure which Groovy features are the bottlenecks, but dynamically typed variables are sure to be slower than statically typed ones. – Peter C Mar 08 '11 at 22:39
  • It would be very useful to locate the results & tests executed that associated this release of Groovy. http://docs.codehaus.org/display/GROOVY/2008/05/02/Groovy+1.6-beta-1+release+with+great+performance+improvements I wonder if the same tests have been run on releases since that date (May 2008). Fishy ... – David Victor Mar 08 '11 at 22:47

8 Answers8

53

It's obviously true that Groovy is compiled to JVM. This however has little to do with the performance.

The most important thing to note here is that Groovy is a dynamic language. This essentially means that most of the time Groovy compiler will have little to no knowledge about the type of an object it is calling a method on / retrieving a property from. This has a huge impact on the performance. There might be thousands of different classes implementing someFancyMethodName() not having a common base class. Yet a call to obj.someFancyMethodName() has to choose the right one. There isn't any better way of doing this than deciding it at runtime based on some kind of reflection. In fact, because of this every single call to a method gets dispatched through a call to invokeMethod() on the object metaclass. This is very much visible in stacktraces if your program ever throws some nasty exceptions. It's even worse. Any class in groovy may choose to provide implementations of methods of the given name dynamically, that is producing them at runtime. There is a fair amount of Grails magic that makes a heavy use of it. Another complication emerges when method overloading comes into play. As the knowledge of types is so limited, it's impossible to choose the right version of the method at compile time. The produced code has to look into the supplied objects and then by making a series of if-elses choose the implementation that best fits the provided call. This most of the time is a really non-trivial process, that was never intended to be performed at runtime. Yet, Groovy has to do it, in order to stay inter-operable with Java.

All that makes Groovy pretty slow. In fact much slower and, what is more painful, more memory consuming than most of the dynamic languages out there (Python for instance).

That said, I agree that the reason for using Groovy is certainly not performance. Most of the time, you will end up optimizing only a small fraction of your code. If performance is such an issue, you can always resort to rewriting those specific pieces in pure Java or give a try to Groovy++. Haven't tried it myself, however the results that I read about online seemed pretty promising.

Groovy 2.0 I have no experience in running the newer version. Quite frankly, I'm not an active Groovy user anymore. I would however expect that most of the issues described above, are fundamentally hard and require a major scientific breakthrough. I have some experience developing HHVM (a PHP virtual machine created by Facebook) and there are much simpler features that performed poorly.

julx
  • 8,694
  • 6
  • 47
  • 86
  • @julkiewicz - thanks for this. Like any robust design need to be aware of pros/cons of a solution & take it into account. – David Victor Mar 09 '11 at 07:18
  • 5
    Of course Groovy is slower than Java, but much of what you say in the second and third paragraph is either wrong or obsolete. Keep in mind that Groovy has advanced a lot over the years. – Peter Niederwieser Mar 09 '11 at 12:33
  • @Peter Could you elaborate on that? I'd be glad to hear about it. I think the speed of Groovy really is a direct result of its design (most dynamic languages don't support any notion of static typing, so they don't have to deal with method overloading other than parameter count which is much cheaper and faster). I don't really see how you could overcome that using caching or any other technique for that matter. – julx Mar 09 '11 at 12:51
  • @julkiewicz Although it is possible to add method's dynamically, most code do not do this. To take advantage of this observation, dynamic languages on the JVM do some kind of JIT-ing; JRuby made huge performance improvements with this technique and I think the Groovy runtime also now has some of those improvements now. – Binil Thomas Mar 09 '11 at 17:11
  • 10
    Actually Groovy 1.8 is very fast, almost close to Java and Scala. This answer is obsolete now. – Wanderson Santos May 15 '11 at 07:26
  • 9
    @Wanderson No it's not. Have you even read the changelog for Groovy 1.8? It does make some improvements in the field of method dispatching, however this mostly concerns primitive types. Now this will sure speed up fibonacci benchmark, the problem is, this is by no means a typical use case. There wasn't any dynamic language so far that would get anywhere near Java. I doubt Groovy with all of its added complexity will ever be faster than Python. – julx May 15 '11 at 16:44
  • 4
    julkiewicz you are partially right and partially wrong in what you say above. Yes, Groovy is only that fast for primitive types, not in general. That is true. That each and every method call has to go through some kind of invokemethod somewhere is not true though. Groovy uses since 1.6 at runtime generated bytecode stubs for call site caching. That allows method invocations without Reflection. the first call is still in general done by Reflection so of course you see it there. – blackdrag May 22 '12 at 08:21
  • 1
    Then there are multiple paths an invocation can take, and one of these is completely through the meta class, where you will see what you claimed above, the invokeMethod method. In the end it depends on your program what is done how and how fast it is in the end.The static compilation mode in Groovy 2 allows only a subset of Groovy, but all that is compiled statically will of course not show those slow invokeMethod paths and memory usage will be lower as well. – blackdrag May 22 '12 at 08:23
  • 1
    One more thing about memory. Groovy uses a lot of caching with SoftReferences. That mean Groovy will take a lot of memory over time, but does not cling to it. I have run rather larger Groovy programs in under 4MB memory available. It all depends on your application. Using ExpandoMetaClass, as Grails does, is a whole other thing and enlarges the memory requirements a lot. – blackdrag May 22 '12 at 08:26
  • @blackdrag Nice info, I'll need some time to digest it though. I'll try to update this answer in a few days. – julx May 22 '12 at 17:11
  • 1
    As it looks at the moment Groovy 2 will have a lot to offer in the dynamics department of Groovy as well. I have here a prototype that let's run the fibonacci example at the same speed using invokedynamic as it currrently does using primitive optimizations. The big difference is that the invokedynamic version is much more agnostic to meta programming and missing types. I am not yet sure what this could in the end mean for for example Grails, but this looks like a really good foundation for a very fast Groovy. Some changes to the MOP may be needed in Groovy to use the full potential later on – blackdrag Jun 01 '12 at 09:27
  • 1
    @julkiewicz Python didn't get close with Groovy features like MOP and AST. I like its clean syntax but Groovy is way more dynamic language. And "doubt" is your opinion, just check the facts. Look at this common use case comparing various frameworks. It's old (uses Grails/Groovy 1.x) but you can see how Groovy performs with Grails - sometimes better than Java/JSP! http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/ – Wanderson Santos Jul 23 '12 at 21:27
  • 1
    Groovy 1.8 already has a great performance and don't need to go to Java at hotspots. Groovy 2.0 with invokedynamic will fly... an awesome job of Guillaume LaForge and Groovy community which focused on syntax and productivity first and now are focusing on performance tweaks. – Wanderson Santos Jul 23 '12 at 21:27
  • Groovy 2.1 do fly with 'invokedynamic' JDK7 support and static checking. Check it out now. Those who complains about Groovy should rethink their opinions based by numbers. For me, since Groovy 1.6 they served me well for huge systems. Now the numbers say by itself for skeptics. Be happy coding! – Wanderson Santos Feb 13 '13 at 18:25
23

So here we are in 2012 and Groovy 2.0 is ready to rock...

"With the @CompileStatic, the performance of Groovy is about 1-2 times slower than Java, and without Groovy, it's about 3-5 times slower. (...) This means to me that Groovy is ready for applications where performance has to be somewhat comparable to Java."

Performance Test: Groovy 2.0 vs. Java http://java.dzone.com/articles/groovy-20-performance-compared

And besides the autor, I've used Groovy since 2008 with great success, not only for CV, just to make job done in time business need. Performance is ever relative to what you want to do.

For those who are complaining about numeric use cases, here goes a real use case using web frameworks: http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

"Groovy 1.8.x prototype for fib(42) takes about 3.8s (only 12% slower than Java, over a hundred times faster than Groovy 1.0) So we may no longer encourage people to write such 'hot spots' in Java."

Source: http://www.wiki.jvmlangsummit.com/images/0/04/Theodorou-Faster-Groovy-1.8.pdf

"I'm impressed on how much Groovy's performance has improved for numerical computing. Groovy 1.8 in my project jlab (http://code.google.com/p/jlabgroovy/) sometimes outperforms Scala's performance in my other project ScalaLab (http://code.google.com/p/scalalab) !!"

Source: http://groovy.329449.n5.nabble.com/Great-improvements-in-Groovy-s-performance-for-numerical-computing-td4334768.html

Wanderson Santos
  • 2,917
  • 1
  • 26
  • 16
  • See also: http://docs.codehaus.org/display/GROOVY/Groovy+1.8+release+notes#Groovy1.8releasenotes-Performanceimprovements – David Victor Jul 10 '11 at 07:23
  • 6
    I think this answer is misleading. Groovy is still 12% slower in one specific area relating to a purely numerical computation. For the overall picture I suggest read @julkiewicz answer. – David Victor Jul 10 '11 at 07:28
  • 2
    @DavidVictor you were talking about a dynamic language versus an statically typed. Only 12%? It's AWESOME! You are talking about a really dynamic language with MOP and AST! With Groovy 1.8 it got even close. Now just check Groovy 2.0... Groovy is not just way ahead all dynamic languages in features but the faster dynamic (really dynamic) language not only on JVM, but PHP, Phyton and other dynamic languages too. Best regards! – Wanderson Santos Jul 23 '12 at 21:33
  • A year later !? I still think the answer was misleading. Where is the evidence (performance test results) for your latest comment ? – David Victor Jul 24 '12 at 07:00
  • Do the evolution baby! You could have looked at this old micro-benchmark: http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/ or this real-world benchmark: http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/, but I think it's better this fresh new article: http://java.dzone.com/articles/groovy-20-performance-compared – Wanderson Santos Sep 02 '12 at 04:35
  • 2
    What's lost in this - your use of @CompileStatic causes so many restrictions and side-effects, you may as well not call it Groovy. – Καrτhικ Aug 05 '14 at 11:20
  • Definitely a quote from a sales pitch. In practice six years later i tell you that @CompileStatic is an irrelevant feature. – Lothar Apr 13 '21 at 09:51
12

Groovy offers a lot more syntactic sugar over Java, but still runs on the JVM and therefore requires a bit more work by the JVM to provide that sugar. Nevertheless, the difference is extremely minor in the vast majority of normal usages.

In addition, if you do happen to write a function that runs too slowly in Groovy, you can write it in straight Java and call it from your Groovy code. That's the team's recommended solution, and I can vouch for it working well and simply.

It my opinion, for the programming most of us do, it's a non-issue.

Melv
  • 2,201
  • 16
  • 14
8

A quick Google search yielded some old performance results (http://www.codecommit.com/blog/java/groovys-performance-is-not-subjective, http://www.christianschenk.org/blog/performance-comparison-between-groovy-and-java/).

Groovy++ looks interesting also (http://stronglytypedblog.blogspot.com/2010/02/java-vs-scala-vs-groovy-vs-groovy.html).

However, the reason to use Groovy should be because it improves your performance not the computers...

Matthew
  • 238
  • 2
  • 7
3

I think , you have to look at this scientific comparison of Groovy Vs Python Vs PHP vs Ruby.

http://blog.websitesframeworks.com/2013/11/comparison-of-programming-languages-ruby-groovy-python-and-php-353/

They have made one exercise and produce comparison on these programming languages on the below factors:

Comparison of time developing each exercise

Comparison of readability of the languages

Comparison of results in benchmarks and lines of code. From the project Computer Language Benchmarks Game

Conclusions

It is a great quick study to enable you which language is better.

Jay Modi
  • 3,161
  • 4
  • 35
  • 52
Mohamed Ibrahim
  • 51
  • 3
2

Generally speaking, Groovy will be slower. You can avoid that by switching to Groovy++ which offers most of the features of Groovy, but can be statically compiled and has performance comparable to Java.

Jochen Bedersdorfer
  • 4,093
  • 24
  • 26
  • Slowness is relative and with Groovy 1.8 you will have to think again about it: http://regispires.wordpress.com/2010/10/23/comparacao-de-performance/ – Wanderson Santos Jun 14 '11 at 20:28
  • 2
    That might well be. I was speaking in general terms. And that was from March 8th. And I'm not sure why you are linking to this blog post. It looks kinda spanish to me – Jochen Bedersdorfer Jun 17 '11 at 17:06
0

While developing AWS Lambdas Java will be faster than groovy. Apart from that in all other scenarios you might not feel much difference.

Khwaja Sanjari
  • 455
  • 5
  • 17
-12

Groovy is compiled to bytecode .class files but running Groovy classes requires ~5MB groovy library that make performance overhead.

8bit
  • 1
  • 1
    just the 5MB of the groovy lib don't make the performance overhead.. its the amount of instructions required to be created by the compiler to support groovys syntax that is making it slow in the end (meaning the amount of instructions the jvm then has to execute at runtime) – Dominik Dorn Aug 16 '13 at 09:01