9

Is there an estimate that says how much JSR-292 will impact Groovy performance?

Kimble
  • 7,295
  • 4
  • 54
  • 77
  • Looks like there's still a long way to go for Groovy code to get certain performance benefit from invokedynamic. My genetic algorithm performed 5 times slower with invokedynamic enabled, and I tested it with Java 1.8.0 and Groovy 2.2.1! You can try for yourself, just clone this: https://github.com/renatoathaydes/MachineLearning and run test `com.athaydes.ml.algorithms.LinearGPTest::testNonTrivialPrograms`. It runs in 4 seconds normally, but with groovy-indy and invokedynamic, it runs in at least 25 seconds. – Renato Apr 06 '14 at 16:56
  • Another post which also showed indy can actually slow down your Groovy code: http://derjan.io/blog/2012/08/08/first-steps-with-groovys-invokedynamic-support/ – Renato Apr 06 '14 at 17:01

4 Answers4

4

invokedynamic is a complicated story really, since the performance characteristics changes all the time in JDK7. During porting Groovy to indy I got really, really near Java, about factor 1.5. But I have to use the catchExceptionGuard, which reduces performance to something like being factor 3-4. We still need to investigate ways to avoid having to use that guard. Maybe we will have to break some existing code in Groovy 2.2 for that. Anyway, I don't need the guard for the invokeMethod fallback as mentioned above. It is for GroovyRuntimeExceptions possibly containing other exceptions, that I have to unwrap or do other things with. So the theoretical possible performance seems to be between Java and half of Java speed for existing methods. Performance of calls to invokeMethod is a whole different story.

If you need more, then use @CompileStatic in Groovy 2.0.

blackdrag
  • 6,413
  • 2
  • 26
  • 38
3

I don't think there is a benchmark yet, and until someone performs it we can only guess...

You may find this post in this matter interesting.

Michael Easter
  • 23,733
  • 7
  • 76
  • 107
David Rabinowitz
  • 29,904
  • 14
  • 93
  • 125
2

It would be around 10-50 times faster in general.

http://www.mail-archive.com/mlvm-dev@openjdk.java.net/msg00819.html

chanwit
  • 3,174
  • 2
  • 23
  • 20
  • 1
    Can you please back that up with some references or evidence? – Michael Easter Jan 06 '10 at 14:13
  • Hi, I have added the link. It's based on my own experience of creating a Groovy compiler over JSR-292. And basically, it's an estimation (as the question has asked for the estimation as well ;) – chanwit Jan 06 '10 at 14:53
  • 1
    Really misleading. I actually got a 5x slowdown with indy enabled. – Renato Apr 06 '14 at 17:03
0

I'm not sure how much is it applicable to Groovy. If I remember well, Groovy has some fallbacks (e.g. invokeMethod method). It is not possible to simply use the fallback with invokedynamic, I think.

However, there are some ways:

  • Catch the exception that is thrown when the method is not found. Unfortunately, it is probably necessary to analyze stacktrace, because you can't be sure where is it thrown from. This can be a signifficant slowdown when calling a non-existing method, regardless it is handled by invokeMethod callback.
  • Look at Groovy++. It allows you to use static typing if you satisfy some contraints. In such case, the it can be possible to allow you to switch to a "strict dynamic mode", which does not allow these fallbacks.
v6ak
  • 1,636
  • 2
  • 12
  • 27