Pruebas de rendimiento con diferentes implementaciones sobre la JVM

Como ya describí en un una noticia anterior, “La plataforma Java y otros lenguajes”, he estado realizando unas pruebas, implementando la misma lógica de negocio en diferentes lenguajes que corren sobre la JVM y también usando diferentes formas de hacerlo en Java.

La segunda parte de las pruebas ha sido comparar el rendimiento las diferentes implementaciones, para ver si había algún aspecto que llamara la atención. Para aquellos interesados, los resultados los podéis en esta entrada: Separating Concerns: Business Logic Implementations performance.

Y como últimamente ha habido un par de noticias comparando rendimientos y parecen interesar, pues he aquí la noticia :).

Como resumen, decir que:

.- Pnuts parece no estar maduro del todo, ya que el rendimiento era bastante malo comparado con el resto, y luego se le detectaron problemas de rendimiento por que lo no aparece en los tests.

.- PHP/Quercus no lo hacia nada mal en los tests, pero tuvo que ser descartado por un “memory leak” en las versiones recientes cuando se le llama a través del Scripting API y un fallo de empaquetado en la última versión.

.- Para algo simple como una consulta básica, las diferencias entre JDBC y librerías más “complejas” (Ibatis, Hibernate, JPA) son mínimas (salvando el caso de la primera petición). Por supuesto que para otros casos las diferencias existirán y serán enormes, pero simplemente quería constatar si por el mero hecho de usar una de estas librerías ya estábamos haciéndolo todo más lento.  Y constatado queda que no es cierto.

.- Groovy usado “correctamente”, lo cual quiere decir no inicializar cada vez un ScriptingEngine nuevo, es prácticamente igual de eficiente que precompilándolo, y prácticamente igual de eficiente que Java. De nuevo, seguro que para muchas otras cosas Java es mucho más eficiente, pero para consultar una BDD y “escupir” XML, parece que los dos lo hacen igual de bien.

.- A Scala y Jython parecen gustarles los conjuntos de datos grandes y las peticiones simultáneas, donde aparentemente le sacan más partido a la forma funcional/recursiva de trabajar.

.- Al contrario, a JavaScript no le gustan los conjuntos de datos grandes ni las peticiones simultáneas.Y concatenando cadenas aún menos que usando el API E4X.

.- JRuby ha sido en muchos casos el más lento, exceptuando a JavaScript y una vez descartado Pnuts, pero tampoco me quedo muy convencido puesto que no soy ningún experto en este lenguaje y podría ser cuestión mía. De todas formas la función es muy sencilla y nadie sugirió ninguna versión más “Rubish”, así como en Jython y Scala sí que los expertos en esos lenguajes me mandaron sugerencias, así que, en principio, ahí queda.

El código fuente de todas las implementaciones, la aplicación de prueba y los scripts del JMeter para ejecutar los tests están todos disponibles, por si alguien quiere repetirlos. O por si alguien quiere cambiar el código para hacer otro tipo de pruebas.

De todas formas y como en cualquier micro-prueba, hay que tomarse los resultados con algo de sano escepticismo y hay que saber qué es lo que se está mirando. Extrapolar alegremente los resultados es equivocado.