ejemplo - ¿Cómo se compara el rendimiento de Groovy con Java?
private jlabel (7)
Así que aquí estamos en 2012 y Groovy 2.0 está listo para rockear ...
"Con @CompileStatic, el rendimiento de Groovy es aproximadamente 1-2 veces más lento que Java, y sin Groovy, es aproximadamente 3-5 veces más lento. (...) Esto significa para mí que Groovy está listo para aplicaciones donde el rendimiento para ser algo comparable a Java ".
Prueba de rendimiento: Groovy 2.0 vs. Java http://java.dzone.com/articles/groovy-20-performance-compared
Y además del autor, he usado Groovy desde 2008 con gran éxito, no solo para CV, solo para hacer el trabajo en tiempo y necesidad. El rendimiento siempre está relacionado con lo que quiere hacer.
Para aquellos que se quejan de casos de uso numérico, aquí va un caso de uso real usando marcos web: http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/
"El prototipo Groovy 1.8.x para fib (42) requiere aproximadamente 3.8s ( solo 12% más lento que Java, más de cien veces más rápido que Groovy 1.0 ). Por lo tanto, es posible que ya no animemos a las personas a escribir tales ''hot spots'' en Java".
Fuente: http://www.wiki.jvmlangsummit.com/images/0/04/Theodorou-Faster-Groovy-1.8.pdf
"Estoy impresionado de cuánto ha mejorado el rendimiento de Groovy para la computación numérica. Groovy 1.8 en mi proyecto jlab (http://code.google.com/p/jlabgroovy/) a veces supera el rendimiento de Scala en mi otro proyecto ScalaLab (http: //code.google.com/p/scalalab) !! "
¿Cuál es el rendimiento de Groovy en comparación con Java?
Creo que tienes que mirar esta comparación científica de Groovy Vs Python Vs PHP vs Ruby.
Han hecho un ejercicio y producen una comparación en estos lenguajes de programación en los siguientes factores:
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
Es un gran estudio rápido para permitirle qué idioma es mejor.
En general, Groovy será más lento. Puede evitar eso al cambiar a Groovy ++ que ofrece la mayoría de las funciones de Groovy, pero se puede compilar estáticamente y tiene un rendimiento comparable al de Java.
Es obviamente cierto que Groovy está compilado para JVM. Sin embargo, esto tiene poco que ver con el rendimiento.
Lo más importante a tener en cuenta aquí es que Groovy es un lenguaje dinámico. Esto significa esencialmente que la mayoría de las veces el compilador de Groovy tendrá poco o ningún conocimiento sobre el tipo de objeto al que está llamando un método / recuperación de una propiedad. Esto tiene un gran impacto en el rendimiento. Puede haber miles de clases diferentes implementando algunosFancyMethodName () que no tienen una clase base común. Sin embargo, una llamada a obj.someFancyMethodName () tiene que elegir la correcta. No hay mejor forma de hacerlo que decidirlo en tiempo de ejecución en función de algún tipo de reflexión. De hecho, debido a esto cada llamada a un método se envía a través de una llamada a invokeMethod () en la metaclase del objeto. Esto es muy visible en stacktraces si su programa alguna vez arroja algunas desagradables excepciones. Es aún peor. Cualquier clase en groovy puede optar por proporcionar implementaciones de métodos del nombre de pila dinámicamente, que los está produciendo en tiempo de ejecución. Hay una buena cantidad de magia de Grails que hace un uso intensivo de ella. Otra complicación surge cuando la sobrecarga de métodos entra en juego. Como el conocimiento de los tipos es muy limitado, es imposible elegir la versión correcta del método en tiempo de compilación. El código producido tiene que examinar los objetos suministrados y luego, al hacer una serie de if-elses, elige la implementación que mejor se ajusta a la llamada proporcionada. La mayor parte del tiempo es un proceso realmente no trivial, que nunca fue pensado para ser ejecutado en tiempo de ejecución. Sin embargo, Groovy tiene que hacerlo para mantenerse interoperable con Java.
Todo eso hace que Groovy sea bastante lento. De hecho, es mucho más lento y, lo que es más doloroso, consume más memoria que la mayoría de los lenguajes dinámicos (Python, por ejemplo).
Dicho esto, estoy de acuerdo en que la razón para usar Groovy ciertamente no es el rendimiento. La mayoría de las veces, terminará optimizando solo una pequeña fracción de su código. Si el rendimiento es un problema, siempre puede recurrir a la reescritura de esas piezas específicas en Java puro o darle una oportunidad a Groovy ++. No lo he probado yo mismo, sin embargo, los resultados que leí en línea parecían bastante prometedores.
Groovy 2.0 No tengo experiencia en ejecutar la versión más nueva. Francamente, ya no soy un usuario activo de Groovy. Sin embargo, espero que la mayoría de los problemas descritos anteriormente sean fundamentalmente difíciles y requieran un avance científico importante. Tengo algo de experiencia en el desarrollo de HHVM (una máquina virtual PHP creada por Facebook) y hay funciones mucho más simples que funcionaron mal.
Groovy ofrece mucho más azúcar sintáctico que Java, pero aún se ejecuta en la JVM y, por lo tanto, requiere un poco más de trabajo por parte de la JVM para proporcionar ese azúcar. Sin embargo, la diferencia es extremadamente menor en la gran mayoría de los usos normales.
Además, si escribes una función que se ejecuta muy lentamente en Groovy, puedes escribirla directamente en Java y llamarla desde tu código de Groovy. Esa es la solución recomendada por el equipo, y puedo garantizar que funciona bien y de forma sencilla.
En mi opinión, para la programación que la mayoría de nosotros hacemos, no es un problema.
Groovy se compila para codificar archivos .class, pero ejecutar clases Groovy requiere ~ 5MB de una biblioteca groovy que hace que el rendimiento sea elevado.
Una búsqueda rápida en Google arrojó algunos resultados de rendimiento anteriores ( http://www.codecommit.com/blog/java/groovys-performance-is-not-subjective , http://www.christianschenk.org/blog/performance-comparison-between-groovy-and-java/ ).
Groovy ++ parece interesante también ( http://stronglytypedblog.blogspot.com/2010/02/java-vs-scala-vs-groovy-vs-groovy.html ).
Sin embargo, la razón para usar Groovy debería ser porque mejora su rendimiento, no las computadoras ...