Blogs

Corrección a The Great Ruby Shootout

Un día después de haber publicado la edición de diciembre de 2008 de The Great Ruby Shootout, Antonio Cangiano ha realizado una rectificación que cambia los resultados sensiblemente. En primera instancia, había usado el intérprete de Ruby 1.8.7 que viene empaquetado con Ubuntu y los resultados eran bastante impresionantes.

De hecho, sorprendía el buen nivel mostrado por Ruby Enterprise Edition, que superaba en una proporción de 2 a 1 al intérprete oficial.

Sin embargo, compilando "a mano" Ruby 1.8.7, su rendimiento mejora de forma importante y el panorama cambia: Ruby Enterprise Edition ya no supera en rendimiento al MRI y las diferencias respecto a Ruby 1.9.1 y JRuby se acortan bastante (quedando en proporciones de 2.5 y 1.9, respectivamente).

Nosotros ya nos encontramos con ese problema hace unos meses al poner una aplicación en producción. Notamos que iba bastante más lenta en el servidor que en nuestras máquinas de desarrollo, donde teníamos Ruby compilado "a mano". Fue instalarlo desde los fuentes en el servidor y todo cambio drásticamente.

Ruby 1.9.1 y JRuby, los más rápidos

Actualización 11/12/2008: Antonio ha realizado una rectificación y los resultados cambian sensiblemente.

Antonio Cangiano publicó ayer una nueva entrega de su famoso Great Ruby Shootout. En pocas palabras, se trata de una comparativa de rendimiento de las diferentes implementaciones de Ruby existentes, basándose en la Ruby Benchmark Suite.

JRuby y Ruby 1.9.1, los vencedores

Los resultados de esta edición encumbran a JRuby como la mejor implementación de Ruby 1.8, con una proporción de 3.62 a 1 en velocidad de ejecución respecto al intérprete oficial (conocido como MRI, acrónimo de Matz's Ruby Intepreter).

Sin embargo, es el intérprete de la versión 1.9 (basado en YARV) el que ofrece mejores resultados en general, siendo casi cinco veces más rápido que Ruby 1.8 MRI. A este respecto, Charles Oliver Nutter (uno de los autores de JRuby) comentó cuando se finalize el soporte para la versión 1.9 en JRuby las diferencias deberían reducirse de forma sensible.

Importante mejora respecto al año anterior

A tenor de los resultados, podría decirse que tanto Ruby 1.9 como JRuby han experimentado una importante mejora en términos de rendimiento. Sin embargo, hay un factor importante que, en cierto modo, invalida esta comparación: la suite utilizada en las pruebas es diferente (aunque muchas de sus pruebas conserven el nombre).

Ruby 1.9 JRuby Rubinius
2007 3.32 1.32 0.73
2008 4.90 3.62 1.03

Ruby Enterprise Edition, una agradable sorpresa

Una de las sorpresas más agradables en esta edición la protagoniza Ruby Enterprise Edition. Simplificando, se trata de una modificación del intérprete oficial que usa menos memoria. Según sus autores, combinado con Passenger, reduce hasta en un 33% el uso de memoria de una aplicación Rails.

La sorpresa es que en términos de velocidad también parece superar de forma importante al intérprete oficial, con una proporción de 2 a 1.

De hecho, nosotros estamos empezando a adoptar Passenger y Ruby Enterprise Edition para nuestras aplicaciones Rails y, de momento, estamos más que satisfechos.

Otras implementaciones entran en el juego

Además de las habituales y las ya mencionadas (Ruby 1.9, JRuby, Rubinius y Ruby Enterprise Edition), Antonio Cangiano ha incluido otras implementaciones menos maduras pero a las que no conviene perder de vista, como MagLev (cuya presentación en la RailsConf 2008 causó un importante revuelo), IronRuby o MacRuby.

Conclusiones

Siempre hay que tomar con cuidado los resultados arrojados por esta clase de comparativas. Se trata de pruebas sintéticas y no de aplicaciones reales, por lo que una proporción de 5 a 1 no quiere decir que nuestras aplicaciones vayan a ir cinco veces más rápido.

Además, tampoco se tienen en cuenta otros parámetros que pueden resultar importantes como, por ejemplo, el gasto de memoria.

En cualquier caso, parece que hay lugar para el optimismo. En palabras del propio Antonio:

Overall I think these are great results. Ruby 1.8 (MRI), with its slowness and memory leaks, belongs to the past. It’s time for the community to move forward and on to something better and faster - and we don’t lack interesting alternatives to do so at this stage.

Mercurial en el Google Summer of Code

Una de las iniciativas que más me gusta de Google es su ya célebre Summer of Code. En la edición de este año, la cuarta, Mercurial participa con cuatro proyectos.

Partial Clone

Este es mi favorito. A día de hoy, con Mercurial no puedes hacer un clone (o checkout) de una parte del repositorio. Por ejemplo, no puedes traerte únicamente un directorio del repositorio. Algo que sí puede hacerse, por ejemplo, con Subversion.

Para grandes proyectos, esta es una limitación importante. Incluso a nosotros nos hubiera venido bien disponer de ella para uno de los proyectos en que nos encontramos inmersos actualmente.

Rebasing

Esta es otra funcionalidad interesante. Se trata de poder tomar una secuencia de revisiones y cambiarle el padre.

Como se explica en la solicitud del proyecto, puede ser aplicable en varios casos. Por ejemplo, un desarrollador que está trabajando en una rama local puede mantener sus parches actualizados con la principal moviéndolos "al final" de esta.

Mejora de las herramientas de conversión a Subversion

Aunque la popularidad de los sistemas de control de versiones distribuidos ha crecido mucho en los últimos años, lo cierto es que hay aún un número enorme de proyectos que utilizan (y seguirán utilizando) herramientas como Subversion. De hecho, este es el más popular entre los sistemas centralizados.

Si bien Mercurial cuenta con buenas herramientas para convertir repositorios Subversion a Mercurial, lo cierto es que para trabajar en el otro sentido el panorama no es tan bueno.

Mediante este proyecto se intentará mejorar el conjunto de herramientas de conversión, de modo que en el futuro podamos trabajar cómodamente sobre con Mercurial sobre un repositorio Subversion.

Integrar TortoiseHG con un gestor de fichero en Linux

El cuarto y último proyecto tiene dos objetivos:

  • Por un lado, mejorar la integración de TortoiseHG con Nautilus.
  • Y por otro, construir una interfaz gráfica unificada para seguir la evolución de un proyecto.

Aparece Mercurial 1.0 después de tres años

Como desarrolladores de software, consideramos que un buen sistemas de control de versiones es una herramienta básica e imprescindible para realizar nuestro trabajo.

Desde la universidad, cuando tuvimos nuestro primer contacto con el viejo CVS, hemos probado unas pocas: Subversion (como reemplazo directo de la anterior), Darcs (cuando nos interesamos por los "distribuidos") y Mercurial (huyendo de algunos problemas con Darcs), además de tontear con SvK y Git.

Dicho esto, comprenderán que esta semana nos hayamos alegrado al ver que, tras tres años de desarrollo, por fin ha salido la versión 1.0 de Mercurial que es, junto a Darcs, el sistema que usamos actualmente.

Mercurial es un sistema de control de versiones distribuido, rápido y que presume de escalar muy bien. Además, es posible extenderlo usando Python, lo que abre un amplio abanico de posibilidades. De hecho, hay una buena cantidad de extensiones.

A los interesados, les recomiendo que echen un vistazo a la lista de funcionalidades y, para profundizar, la guía no oficial es también muy recomendable.

No más "en casa del herrero..."

Para ser sincero, hace tiempo que perdí la cuenta de las veces que recurrimos al famoso dicho en casa del herrero, cuchara de palo cuando nuestros clientes nos preguntaban por nuestra web. El motivo es que, la mayor parte de nuestros esfuerzos, están precisamente centrados en nuestros clientes y poner en marcha nuestra propia web era una tarea que siempre quedaba relegada al último lugar.

Distribuir contenido