What the performance of Groovy compared with Java?
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.
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
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.”
“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) !!”
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.
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…
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.
I think , you have to look at this scientific comparison of Groovy Vs Python Vs PHP vs Ruby.
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.
While developing AWS Lambdas Java will be faster than groovy. Apart from that in all other scenarios you might not feel much difference.
Groovy is compiled to bytecode .class files but running Groovy classes requires ~5MB groovy library that make performance overhead.