1

According to an article Groovy has

Unfortunately at the same time Groovy is very slow at runtime. As a person, who did a lot to improve performance of Groovy I can probably speak about that very openly. Groovy is very slow. You can easily expect that some Groovy calculation or data transformation rewritten in Java will become 3-5 times faster. Usually this factor is 8-12 and sometimes even higher. Someone can say that Java is always at our service and nobody uses Groovy for calculations or data processing... But, hey, it is exactly my point - why should we limit ourselves for just scripting or handling of simple web pages?

What is even worse is the fact that Groovy doesn't scale well for multi-core computers meaning that several threads executing code compiled by Groovy really prevent each other from being fast. It is not a problem for many applications but for many others it is simply show-stopper.

Could someone proof or refute that paragraphs?

I am particularly concerned about multi threading performance.

FoxyBOA
  • 5,788
  • 8
  • 48
  • 82

4 Answers4

6

There are ongoing efforts to improve the speed of Groovy, but it should be said that 9 times in 10, the performance is not an issue.

However, where it is an issue you can either write that code in Java (and integrate that Java class easily into your Groovy code), or if you want to remain completely groovy, you can look into using Groovy++ which improves the speed of Groovy by making it more statically typed (with some heavy type inference to save you having to do it all yourself as with Java)

Groovy 1.8b4 (currently in beta), also comes with the GPars framework bundled with it.

The GPars project offers developers new intuitive and safe ways to handle Java or Groovy tasks concurrently, asynchronously, and distributed by utilizing the power of the Java platform and the flexibility of the Groovy language.

{edit July 2012}

Groovy 2.0 has a CompileStatic annotation which you may want to look into (as now Groovy++ has not been developed for quite a few months). This question here has some numbers...

Community
  • 1
  • 1
tim_yates
  • 167,322
  • 27
  • 342
  • 338
  • Thank's Tim. I'm aware of Groovy++ (see my original link). What I indeed missing with Groovy++ is an Eclipse support (AFAIK standard Groovy plugins doesn't work with ++ version). Also I'm highly interesting in ++ version because of mentioned static compilation (I big fan of it). And my last point here Groovy++ looks for most people more simpler than Scala and closer to php/VB. – FoxyBOA Feb 06 '11 at 09:44
  • @FoxyBOA It is a clever project indeed, but yeah, the tooling isn't there yet. I write processor intensive code (Genetic database analysis), and use groovy for its brevity, readability (and the fact it makes coding fun again), but whenever I need the raw performance, it's so easy to write that bit as pure java and just call the class from Groovy that it seriously doesn't feel like a problem... – tim_yates Feb 06 '11 at 09:48
6

Usually this factor is 8-12 and sometimes even higher. Someone can say that Java is always at our service and nobody uses Groovy for calculations or data processing... But, hey, it is exactly my point - why should we limit ourselves for just scripting or handling of simple web pages?

We don't need to limit ourselves anymore! Groovy 1.8 is out! ;-)

"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

Now it's Groovy vs. Scala in performance! Please check it out:

"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

For parallel processing, you can use the already bundled GPars!

Cheers

Wanderson Santos
  • 2,917
  • 1
  • 26
  • 16
3

I can only provide anecdotal evidence of poor Groovy performance in calculations (which is, admittedly, about 2 years old):

I implemented an optimization algorithm in Groovy and found it intolerably slow. Profiling it showed that it spent about 60% of its time in BigDecimal.divide(). The culprit turned out to be one line with a very simple arithmetic calculation on float values that Groovy somehow insisted on transforming into BigDecimal. I tried to avoid having it do that for a bit but failed, so I rewrote that part of the application in Java and saw execution times go down 90%.

Michael Borgwardt
  • 342,105
  • 78
  • 482
  • 720
2

"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 have just tried it and it is extremely inaccurate. Groovy 1.8 for fib(42) is ~ 25 times slower than java. In my test java fib(42) takes 2 seconds where 1.8 and 1.7.8 take about 52 seconds to complete.

Groovy is still slow ....

Amad
  • 21
  • 1