Groovy es lento porque hace magia

Hombre... tampoco me parece malo participar en polémicas, ni hay que obviarlas por antiguos flames. Además en este caso, todos reconocemos que es verdad: Groovy va más lento que otros lenguajes de script sobre la VM.

Otra cosa es que eso sea inherente al lenguaje (lo cual me parece imposible en el caso de cualquier lenguaje) como algunos parecen querer mostrar (no en el caso del hilo de jH). Que se mejorará el rendimiento es algo de cajón, pero no está de más recordar las ventajas de groovy en estos tiempos. ¿O acaso no recordábamos las ventajas de la VM en las eternas polémicas sobre la velocidad de Java, cuando en el caso del escritorio el tema de la velocidad si era un problema?

Salu2   

Sobre todo, y antes de nada, dejar claro que mi intención al proponer esa conversación (mejor conversación que discusión) era únicamente la de... hablar. No tengo nada en contra de Groovy. De hecho mi relación básica con Groov y es... desconocimiento. Y desde esa situación, evidentemente no puedo tener nada en contra.

Simplemente me llamó la atención por un lado la diferencia de rendimiento y por otro esa actitud que se comentaba en el artículo original. Ni siquiera pretendía decir que esa actitud sea cierta. Sólo que, en caso de serlo, me planteaba alguna duda. Y duda algo más general que lo estrictamente relacionado con Groovy, porque igual que señalas las antiguas peleas sobre el rendimiento de Java vs C o C++, la respuesta de "para las partes críticas usa otro lenguaje" es también una respuesta antigua.

Pero bueno, aclarado eso, me pregunto ahora, al ver tu respuesta, ¿qué magia hace Groovy que no hacen otros lenguajes? (Porque, claro, si otros también la hacen y no tienen ese problema entonces la respuesta no es válida) Y ¿tanto cuesta realmente esa magia?

Por otro lado, ¿cómo se conjuga que la magia sea muy cara en recursos de máquina pero que luego en producción vaya como la seda? ¿Podrías explicar esto un poco más, por favor?

A mi lo que me parece mentira es que tras tantos años de flames en Java con el mismo tema y el SanBenito que le ha quedado a Java por no aclarar las cosas desde el principio, algunos insistan en la comunidad Groovy en repetir los mismos errores que se cometieron en el caso Java.

Entre ellos, menospreciar las opiniones de los demas a los que si les afecta el rendimiento poniendo excusas o desviando el tema. Como dice Ibon y le costo a Java aprender. La cosa es más simple: Si, es lento para algunas cosas. Si no te va bien en tu caso, espera que mejorará o usa otra cosa. El resto es intentar hacer que los demas comulguen con ruedas de molino.

¿Tanto cuesta admitir que hay gente a la que no le sirve lo que a nosotros si? 

Vamos a ver... Está claro (clarísimo) que no existe la herramienta perfecta, que Groovy desde luego no lo es, y que la virtud de un buen desarrollador está en saber elegir la herramienta adecuada para cada caso. Simplemente no pensé que hacía falta decirlo, otra vez.

Lo que quería decir al comparar esta polémica con la de Java, es que, al menos yo, la vivía con un sentimiento de lejanía: mientras mucha gente decía que Java se ejecuta más lentamente y consume muchos más recursos que C++, yo vivía encantado por la cantidad de cosas que podía hacer con Java y no con C++, como olvidar la gestión de memoria, desarrollar y compilar en Windows y desplegar en Linux, en fín, lo que todos sabemos. Java sigue siendo más lento que C++, pero yo pensaba que ya estaba superado el síndrome de "mi lenguaje es más rápido que el tuyo". Simplemente a mí me vale Java y a otra mucha gente no. Con Groovy pasa lo mismo: a mí me vale, es suficientemente rápido para mí y aumenta radicalmente mi productividad. Si a alguien no le vale Groovy para lo que quiere hacer, obviamente, deberá buscar otro lenguaje.

Venkman: como sabes, Groovy es un lenguaje dinámico, que permite hacer cosas como añadir métodos a un objeto en tiempo de ejecución, y otras muchas cosas que multiplican la productividad (aunque hay que usarlas con cuidado para que el código siga siendo mantenible, claro). Pero también es un lenguaje que se compila a bytecodes idénticos a los de Java. Ese proceso se realiza al inicializar la aplicación, y una vez en marcha lo que se ejecuta en memoria es básicamente Java. Si haces un benckmark de renderizado 3D seguramente obtendrás un rendimiento muy pobre con Groovy respecto a Java, pero para el uso general la pérdida de rendimiento no es apreciable.

Por cierto, lo de decir que si algo es muy lento con Groovy pudes hacerlo con Java no tiene nada que ver con decir lo mismo de Java vs C. Groovy no nace con la vocación de sustituir a Java, nadie ha pensado eso nunca ni nadie lo intentará hacer. Si prentendes reconstruir una aplicación Java con Groovy estás simplemente perdiendo el tiempo. Groovy nace con la vocación de ser un lenguaje más en la plataforma Java, que se ejecuta en la JVM y colabora con Java 1 a 1. Una clase Groovy es una clase Java, no hay que meter ninguna capa de abstracción al estilo JNI para mezclar Java con Groovy porque ambos viven en la misma plataforma.

yo pensaba que ya estaba superado el síndrome de "mi lenguaje es más rápido que el tuyo"

Naaa, esas cosas no se superan, solo son cíclicas :). Yo lo unico que quiero decir es que si alguien dice "es que con Groovy, la operacion X es mas lenta", la respuesta adecuada no es "Es que Groovy te permite mas cosas, Groovy se usa en producción en tal sitio..." La respuesta, como bien dices, es o "Si, lo es. Para eso mejor no usar Groovy, hombre" o "Si, lo es, pero es un tema que se tiene que mejorar". Todo lo que empiece con "pero es que..." es desviar el tema.

Respecto a la "magia" vs produccion... tambien hay que tener en cuenta que Groovy sufre ahora lo que le pasaba a Java al principio, y es que ahora el JIT y la JVM son una maravilla y la interpretacion de bytecode/compilacion a nativo va como la seda. Y eso es, en parte, lo que le pasa con Groovy y su "traduccion inicial a bytecode". Así que si usas Groovy "dinamicamente", es, por hacer una analogia, como si ejecutaras una JSP compilandola cada vez. Pero claro, en produccion no andas modificando cada vez tus scripts asi que no lo ejecutas en modo "interpretado" y entonces solo te queda el overhead de "la magia" que usa Groovy, el cual en algunos casos si puede ser algo mas lento, que es donde estan trabajando, y en otros muchos casos la diferencia de rendimiento es asumible vs "tiempo total de respuesta".

Pero como dice Nacho, la integración es muy muy sencilla, asi que te animo a que te mojes un poco los pies con el, venkman, para que puedas tenerlo mas claro. Si quieres hacer cuatro pruebas, tengo un proyecto de demo que es bastante ilustrativo.

S!