The machine and the code are the same as the previous tests. The only thing change is that I am using groovy2.0. To make it the results more clear, I am only including the results for f(30) and f(50):
| n | implementation | result | Java | Groovy2 | Groovy2 @CompileStatic | Scala |
|---|---|---|---|---|---|---|
| 30 | for-loop | 832040 | 0 (ms) | 0 (ms) | 1 (ms) | 0 (ms) |
| 30 | recursive | 832040 | 19 (ms) | 66 (ms) | 20 (ms) | 20 (ms) |
| 50 | for-loop | 12586269025 | 0 (ms) | 0 (ms) | 0 (ms) | 0 (ms) |
| 50 | recursive | 12586269025 | 182462 (ms) | 356920 (ms) | 176468 (ms) | 180898 (ms) |
I split the Groovy test to two. One with the new annotation @CompileStatic (I put it in the class level) and one without. The one without is suppose to use the JDK7 new feature invokeDynamic which should give some performance gain but unfortunately JDK7 is not supported in Mac Snow Leopard. @CompileStatic is a new feature that give performance gain to groovy code with type safety check where dynamic features are not required. More information here.
The results show that the big performance gain by adding the @CompileStatic which is making Groovy up to par with Java and Scala. The common ways for Groovy developers to solve performance's problem is to write that piece of code in Java. Now with this new @CompileStatic, everything can be just in Groovy. And the ideal case is that if the JDK7 invokeDynamic gives Groovy2 the same performance as Java, then the @CompileStatic is not needed at all (if you want type safe, you can just use another new annotation @TypeChecked).
No comments:
Post a Comment