6 ms·

I'm surprised more people aren't just using Groovy. The performance of Groovy 2.0 on JVM 7 is greatly improved to the point where its a non-issue in 95% of sit

by mbell 14y ago

I'm surprised more people aren't just using Groovy. The performance of Groovy 2.0 on JVM 7 is greatly improved to the point where its a non-issue in 95% of situations (and you can just drop to java for those portions with no penalties).

mgkimsal 14y ago
I tend to agree with you, but Groovy 2 is still pretty new. In my experience, most of the hardcode Java shops and devs that rejected Groovy (primarily?) because of speed are generally slow-adopters, and wouldn't be using Groovy 2 just because it was released a few months ago. As to speed, I've not benchmarked it on JDK7, so I'm not sure what effect the InvokeDynamic stuff has yet, but @CompileStatic annotation helps a lot. My fibonacci stuff at https://github.com/mgkimsal/newgroovy2 https://github.com/mgkimsal/newgroovy2 (did a presentation on groovy2 last week) showed: fibonacci run of 30: * pure java (not in the github) - 12ms * groovy2 compilestatic - 18ms * groovy2 dynamic with typedefs - 30ms * groovy2 no typedefs - 500ms So yes, while @CompileStatic groovy2 is technically approx 40-50% 'slower' in these tests, the noticeable diff for a lot of projects (especially considering file and db access will be constants regardless) will be likely negligible.
- rforax 14y ago
  @CompileStatic is a great idea even if I prefer approach like Dart or ActionScript partial typing. Groovy closure used dynamic scoping rules not unlike 'this' in JS which makes Closure a corner case for the static analysis performed by @CompileStatic.
- mbell 14y ago
  Just for the sake of comparison, I ran your groovy code vs a similarly styled ruby version of fib. Groovy 2.0.1 (simply ran with 'groovy fib.groovy') JVM 1.7.0_06_64-b24 ~520ms Ruby 1.9.3p194 ~475ms Obviously this is well into micro-benchmark territory but it seems even worse case is on the order of ruby's performance which is perfectly acceptable for a large number of tasks.
  - mgkimsal 14y ago
    Is that the @compilestatic one with 520ms ?! I'd imagine not. Certainly Ruby's acceptable for a large number of tasks, as is Groovy. I use it every day, and will enjoy the speed benefits of Groovy2 in Grails2.x in the coming months, but it's certainly production ready for a large number of tasks now. As many people continue to point out, if Groovy's slow, write those portions in pure Java. But you can get a lot of the way there just by using explicit types when you know them. The @CompileStatic is yet another performance boost, but you can often get improved Groovy perf by typing if you want to.
    - mbell 14y ago
      520ms was for the full dynamic version. But we did have a snafu. The 'groovy' program seems to choose its JVM in an odd way, it was using Apple's 1.6 JVM despite 'java -version' returning the 1.7 JVM. I fixed this by setting JAVA_HOME and now get ~300ms for the full dynamic version, 22ms for explicit types and 586ms for the @CompileStatic version. I'm guessing my method of running this is not compatible with @CompileStatic given its results. Did you run this through groovyc and package it into a jar for your tests? This is on a 2012 MBA with the i5 cpu btw.
      - mgkimsal 14y ago
        I actually ran through the intellij version 12 EAP "LEDA" which has Groovy 2 in it for most of the tests. The @compilestatic stuff should work regardless, but you do need to import the compilestatic transform. import groovy.transform.CompileStatic
        mbell 14y ago
        Well I ran it in IntelliJ and saw the same results. Then I found the problem... I used compile_static3.groovy from your repo for the test which contains the following: bench(d, "fib_dynamic", 30, "Full dynamic ") bench(d, "fib_integer", 30, "Groovy w/ explicit types") bench(d, "fib", 40, "Explicit type w/@CompileStatic") Notice the '40' on the last line :p Corrected results: Full dynamic took 305 ms Groovy w/ explicit types took 22 ms Explicit type w/@CompileStatic took 7 ms Which is much more like what I expected compared to Ruby at 475ms.
- vorg 14y ago
  Groovy 2.0 was only released a few months ago, and isn't production ready. Groovy 2.0 has two jars in it, one with static-compilation and static-inference grafted on, and the other with optimizations for JDK 7's invoke-dynamic bytecode. Programmers can't use both static-compilation and invoke-dynamic in the same source file. Also, both jars seem to have problems. Groovy 2.0.4 was released yesterday only 2 weeks after version 2.0.2 was released "to fix static compilation and type inference problems". Grails 2.2-rc-1 (actually the first beta and not a serious "release candidate" for production use, because the releases called "beta" are really alphas) has only just been released, the first with Groovy 2.x, with only the static-compilation jar from Groovy 2.0.2 bundled, not the invoke-dynamic jar. The facilities of the invoke-dynamic jar might never be merged into the static-compilation jar. There seems to be some infighting at SpringSource over who's in control of Groovy. Version 2.0.3 was skipped because the P.M. "compiled it on the JDK 6 instead of JDK 7 by mistake", which looks like a political play by Guillaume Laforge, SpringSource's project manager for Groovy, against Jochen Theodorou, their technical lead who's done most of the programming work on Groovy since 2004. A year ago, Laforge hired another developer, Cedric Champeau, to put static type inference and compilation into Groovy, in order to mitigate a SpringSource business threat by Alex Tkachman's Groovy++, a static-compilation addon to Groovy which has since been abandoned. Groovy++ had to switch from supporting Groovy 1.8 to 1.7 for a while during its development because of compatibility problems in subsequent beta releases of Groovy, which may have been deliberate, and at the very least, Groovy++ served as an "inspiration" for Groovy 2.0's static-compilation jar. It's looking like Theodorou's invoke-dynamic bytecode optimizations aren't being merged into the static-compilation jar because of a power play by Laforge and Champeau who control the static-compilation jar. The project manager is diluting Theodorou's technical importance to Groovy and thus increasing his own influence. Concerning your benchmarks of Groovy with Java, you left out Scala and Clojure, also popular JVM languages, and you chose an algorithm not used much in business. Both Scala and Clojure have lazy-evaluation in their library lambdas/functions, as will Java 8. Groovy only enables strict evaluation, which slows down many computations used in real business programming scenarios, of which fibonacci isn't one. Lazy-evaluation isn't in the pipeline for Groovy anytime soon. Its "GDK" utility methods were mostly written early on by a programmer without the aptitude for developing anything too complex, such as lambdas with lazy-evaluation. Seems like JDK 8's lambdas, due to ship in about a year, will be the first time Groovy will enable lazily-evaluated computations, long after Scala and Clojure. As for the invoke-dynamic bytecode optimizations being merged into the main jar used by Groovy 2.0 and Grails 2.2, JRuby's long stolen that show. It might never happen with Groovy. And of course there's no spec for Groovy, unlike Scala's detailed spec or Clojure's function doc-strings. Without a spec, Groovy is still single-platform, unlike Clojure and Scala, and many other JVM languages that began their life somewhere else first. So I don't think slow adoption by Java shops that were concerned about Groovy's performance is the reason more businesses don't adopt Groovy. It's more likely that the static-compilation code isn't production ready, just laden with problems, political infighting at SpringSource, trailing behind other languages in lazy-evaluation of lambdas (Clojure, Scala) and invoke-dynamic optimizations (JRuby), an informal-only spec that changes between point releases, the names "Groovy" and "G-Strings" evoking drug use and discrimination against female employees, and a general sense by technical managers that there's a price to be paid later down the line if they adopt Groovy.
benmccann 14y ago
Groovy 2.0 isn't really used because it's so new. E.g. you can't use Groovy 2.0 with Grails until Grails 2.2 is released.
- mbell 14y ago
  While I understand that its not like Groovy requires a large change to start using (unless your running Grails I guess). I just started using it a month ago when I ran into a hunk of JSF controller code that would be drastically simplified with the use of closures. It only took 1 dependency in the pom and a tweak to the maven compiler plugin and I was off and running. It integrates so easily with Java that no code changes anywhere but the controller I was writing were needed.

by mbell 14y ago

mgkimsal 14y ago

I tend to agree with you, but Groovy 2 is still pretty new. In my experience, most of the hardcode Java shops and devs that rejected Groovy (primarily?) because of speed are generally slow-adopters, and wouldn't be using Groovy 2 just because it was released a few months ago. As to speed, I've not benchmarked it on JDK7, so I'm not sure what effect the InvokeDynamic stuff has yet, but @CompileStatic annotation helps a lot. My fibonacci stuff at https://github.com/mgkimsal/newgroovy2 https://github.com/mgkimsal/newgroovy2 (did a presentation on groovy2 last week) showed: fibonacci run of 30: * pure java (not in the github) - 12ms * groovy2 compilestatic - 18ms * groovy2 dynamic with typedefs - 30ms * groovy2 no typedefs - 500ms So yes, while @CompileStatic groovy2 is technically approx 40-50% 'slower' in these tests, the noticeable diff for a lot of projects (especially considering file and db access will be constants regardless) will be likely negligible.

rforax 14y ago
@CompileStatic is a great idea even if I prefer approach like Dart or ActionScript partial typing. Groovy closure used dynamic scoping rules not unlike 'this' in JS which makes Closure a corner case for the static analysis performed by @CompileStatic.
mbell 14y ago
Just for the sake of comparison, I ran your groovy code vs a similarly styled ruby version of fib. Groovy 2.0.1 (simply ran with 'groovy fib.groovy') JVM 1.7.0_06_64-b24 ~520ms Ruby 1.9.3p194 ~475ms Obviously this is well into micro-benchmark territory but it seems even worse case is on the order of ruby's performance which is perfectly acceptable for a large number of tasks.
- mgkimsal 14y ago
  Is that the @compilestatic one with 520ms ?! I'd imagine not. Certainly Ruby's acceptable for a large number of tasks, as is Groovy. I use it every day, and will enjoy the speed benefits of Groovy2 in Grails2.x in the coming months, but it's certainly production ready for a large number of tasks now. As many people continue to point out, if Groovy's slow, write those portions in pure Java. But you can get a lot of the way there just by using explicit types when you know them. The @CompileStatic is yet another performance boost, but you can often get improved Groovy perf by typing if you want to.
  - mbell 14y ago
    520ms was for the full dynamic version. But we did have a snafu. The 'groovy' program seems to choose its JVM in an odd way, it was using Apple's 1.6 JVM despite 'java -version' returning the 1.7 JVM. I fixed this by setting JAVA_HOME and now get ~300ms for the full dynamic version, 22ms for explicit types and 586ms for the @CompileStatic version. I'm guessing my method of running this is not compatible with @CompileStatic given its results. Did you run this through groovyc and package it into a jar for your tests? This is on a 2012 MBA with the i5 cpu btw.
    - mgkimsal 14y ago
      I actually ran through the intellij version 12 EAP "LEDA" which has Groovy 2 in it for most of the tests. The @compilestatic stuff should work regardless, but you do need to import the compilestatic transform. import groovy.transform.CompileStatic
      - mbell 14y ago
        Well I ran it in IntelliJ and saw the same results. Then I found the problem... I used compile_static3.groovy from your repo for the test which contains the following: bench(d, "fib_dynamic", 30, "Full dynamic ") bench(d, "fib_integer", 30, "Groovy w/ explicit types") bench(d, "fib", 40, "Explicit type w/@CompileStatic") Notice the '40' on the last line :p Corrected results: Full dynamic took 305 ms Groovy w/ explicit types took 22 ms Explicit type w/@CompileStatic took 7 ms Which is much more like what I expected compared to Ruby at 475ms.
vorg 14y ago
Groovy 2.0 was only released a few months ago, and isn't production ready. Groovy 2.0 has two jars in it, one with static-compilation and static-inference grafted on, and the other with optimizations for JDK 7's invoke-dynamic bytecode. Programmers can't use both static-compilation and invoke-dynamic in the same source file. Also, both jars seem to have problems. Groovy 2.0.4 was released yesterday only 2 weeks after version 2.0.2 was released "to fix static compilation and type inference problems". Grails 2.2-rc-1 (actually the first beta and not a serious "release candidate" for production use, because the releases called "beta" are really alphas) has only just been released, the first with Groovy 2.x, with only the static-compilation jar from Groovy 2.0.2 bundled, not the invoke-dynamic jar. The facilities of the invoke-dynamic jar might never be merged into the static-compilation jar. There seems to be some infighting at SpringSource over who's in control of Groovy. Version 2.0.3 was skipped because the P.M. "compiled it on the JDK 6 instead of JDK 7 by mistake", which looks like a political play by Guillaume Laforge, SpringSource's project manager for Groovy, against Jochen Theodorou, their technical lead who's done most of the programming work on Groovy since 2004. A year ago, Laforge hired another developer, Cedric Champeau, to put static type inference and compilation into Groovy, in order to mitigate a SpringSource business threat by Alex Tkachman's Groovy++, a static-compilation addon to Groovy which has since been abandoned. Groovy++ had to switch from supporting Groovy 1.8 to 1.7 for a while during its development because of compatibility problems in subsequent beta releases of Groovy, which may have been deliberate, and at the very least, Groovy++ served as an "inspiration" for Groovy 2.0's static-compilation jar. It's looking like Theodorou's invoke-dynamic bytecode optimizations aren't being merged into the static-compilation jar because of a power play by Laforge and Champeau who control the static-compilation jar. The project manager is diluting Theodorou's technical importance to Groovy and thus increasing his own influence. Concerning your benchmarks of Groovy with Java, you left out Scala and Clojure, also popular JVM languages, and you chose an algorithm not used much in business. Both Scala and Clojure have lazy-evaluation in their library lambdas/functions, as will Java 8. Groovy only enables strict evaluation, which slows down many computations used in real business programming scenarios, of which fibonacci isn't one. Lazy-evaluation isn't in the pipeline for Groovy anytime soon. Its "GDK" utility methods were mostly written early on by a programmer without the aptitude for developing anything too complex, such as lambdas with lazy-evaluation. Seems like JDK 8's lambdas, due to ship in about a year, will be the first time Groovy will enable lazily-evaluated computations, long after Scala and Clojure. As for the invoke-dynamic bytecode optimizations being merged into the main jar used by Groovy 2.0 and Grails 2.2, JRuby's long stolen that show. It might never happen with Groovy. And of course there's no spec for Groovy, unlike Scala's detailed spec or Clojure's function doc-strings. Without a spec, Groovy is still single-platform, unlike Clojure and Scala, and many other JVM languages that began their life somewhere else first. So I don't think slow adoption by Java shops that were concerned about Groovy's performance is the reason more businesses don't adopt Groovy. It's more likely that the static-compilation code isn't production ready, just laden with problems, political infighting at SpringSource, trailing behind other languages in lazy-evaluation of lambdas (Clojure, Scala) and invoke-dynamic optimizations (JRuby), an informal-only spec that changes between point releases, the names "Groovy" and "G-Strings" evoking drug use and discrimination against female employees, and a general sense by technical managers that there's a price to be paid later down the line if they adopt Groovy.

benmccann 14y ago

Groovy 2.0 isn't really used because it's so new. E.g. you can't use Groovy 2.0 with Grails until Grails 2.2 is released.

mbell 14y ago
While I understand that its not like Groovy requires a large change to start using (unless your running Grails I guess). I just started using it a month ago when I ran into a hunk of JSF controller code that would be drastically simplified with the use of closures. It only took 1 dependency in the pom and a tweak to the maven compiler plugin and I was off and running. It integrates so easily with Java that no code changes anywhere but the controller I was writing were needed.