Microbenchmarks, lenguajes dinámicos y la web

Hay una frase en inglés que es "lies, dammed lies and statistics" y viene a significar que tenemos mentiras, malditas mentiras, y las estadísticas, y que se utiliza cuando la gente utiliza datos numéricos y estadísticas para intentar sustentar argumentos que de por sí pueden resultar débiles.

Hace unas semanas alguien me preguntaba en qué lenguaje podía hacer un proyecto web. Yo le contesté que podría probar Groovy o Ruby. A lo que el me respondió que había pensado en Java porque había visto muchos estudios que mostraban que estos lenguajes eran demasiado lentos. Pues bien, ahí tenemos un ejemplo del uso de números para fines interesados, en este caso para mover la balanza hacia un lenguaje u otro.

Es cierto que los lenguajes dinámicos son más lentos que los estáticos, ya que gran parte del procesado de los programas se posterga a tiempo de ejecución. Pero la cuestión es, ¿es esto realmente tan relevante? Quizás hace años lo fuese, en las primeras betas de cada lenguaje, pero ahora mismo definitivamente no lo es. A los que vivimos hace ya muchos años toda la historia del "Java es más lento que C++" creo que nos suena todo esto de algo.

Pero intentaré plasmar un ejemplo en esta entrada que creo que explica el por qué es absolutamente irrelevante la diferencia de rendimiento en el mundo de Internet. Imaginémonos algo de lógica de negocio. Java ahora ya está considerado como rápido, así que ¿cuanto nos podría llevar? Pongamos 10 ms. para hacer fácil el ejemplo. Ahora imaginémonos el mismo código en Groovy cinco veces más lento, o sea que serían 10 milisegundos. La gráfica de rendimiento nos quedaría como sigue:

Una nota: si buscáis por Internet os encontraréis órdenes de magnitud de todo tipo, desde 3x hasta 300x, muchos de estos tests son incorrectos por el hecho de usar tipos de datos primitivos, y cualquiera que haya usado Groovy/Ruby/Python/etc. habréis visto que esos ordenes de magnitud tan grandes son irreales. Si os interesa aquí explican más.

Pero volviendo al ejemplo, partimos de 10 ms. contra 50 ms. que es de por sí una diferencia de rendimiento muy importante (y reitero que lejos de la realidad). ¿Escogeríais directamente Java?, a fin de cuentas parece mucho más rápido. Bueno, antes de contestar y ya que estamos hablando de aplicaciones web, introduzcamos en la gráfica el resto de componentes de una petición típica: DNS, servidores varios, bases de datos, etc. A ver como queda la cosa:



¡Vaya! La diferencia que antes parecía tan enorme ahora ya no lo parece tanto. Aclaro que he utilizado valores que a mi me han parecido adecuados. Seguro que serán diferentes si hacéis un estudio serio sobre el tema, pero creo que no irán desencaminados. Hagamos cuentas:

• DNS: 60 milisegundos


• Latencia: 200 milisegundos


• Apaches, weblogics, tomcats, etc.: 160 milisegundos


• Base de datos: 200 milisegundos

En resumen y sumando nuestra lógica de negocio del caso anterior:

• Lógica de negocio en Java: 630 milisegundos


• Lógica de negocio en Groovy: 670 milisegundos

Sorpresa, sorpresa. Lo que era un 5x ahora es un 1.06x O dicho de otro modo, si antes parecía que había un 500% más de rendimiento ahora se ha convertido en un 6%, y creo que he sido bastante generoso.

Y ¿a dónde quiero ir con todo este análisis? A que si estamos eligiendo un lenguaje para nuestro próximo proyecto, para nuestra plataforma corporativa, para nuestra startup, para ese proyecto de cliente, o para aprender, lo menos en lo que nos debemos fijar es en los microbenchmarks ya que no indican absolutamente nada. Hay excepciones. Claro que sí, siempre las hay. Por ejemplo si tenemos que programar algún algoritmo de cálculo intensivo que sólo hará eso, calcular, y donde no influyen factores externos; o programando autómatas; o creando aplicaciones en entornos muy limitados como móviles. En estos casos tenemos que tener más cuidado, pero no es lo habitual.

En la mayor parte de los casos lo más razonable es fijarse en otras características como lo fácil que será programar, el soporte de entornos de desarrollo, lo amplia que es la comunidad de ese lenguaje, la cantidad de documentación y libros disponibles, la cantidad de programadores que voy a poder encontrar en el mercado laboral, lo difícil que pueda ser la curva de aprendizaje, y muchas otras cosas que seguro que se os ocurren.

Pero el rendimiento.... ya no es tan fundamental como antes.