Rendimiento de GIT vs PLASTIC
¡Rendimiento! Me estoy empezando a obsesionar con esta palabra. Casi desde el principio del proyecto el rendimiento ha sido una de mis principales preocupaciones:
el poder realizar las operaciones de update (obtener) cada vez más y más rápido.
Si recuerdo bien, varios meses antes de lanzar nuestra versión inicial ya estaba comprobando si Plastic era más rápido que Perforce actualizando el espacio de trabajo, una de las operaciones más comunes de un control de versiones.
Hubo un momento en el que éramos capaces de superar a Perforce (que dice ser la solución SCM rápida del mercado), con lo que estaba tremendamente satisfecho. Sabía que Perforce era aún más rápido que Plastic haciendo protecciones y añadiendo nuevos fichero, pero nosotros éramos más rápidos actualizando el espacio de trabajo.
Después realicé un test para comparar Plastic y Subversion y…haciendo la operación de “obtener todo” (que descarga de nuevo todo el contendido al espacio de trabajo), ¡y resultamos ser
tres veces más rápidos!
En las últimas semanas he estado trabajando en un cambio importante en el código del selector. ¿Qué quiere decir esto? Bueno, pues los selectores son la pieza clave del sistema de Plastic, tanto si son visibles como si no (la opción visible tan sólo está en la versión profesional de Plastic, pero de todos modos muchos usuarios no quieren preocuparse del selector y prefieren el mecanismo de “cambiar a rama”), juegan un papel importante en el sistema de Plastic.
En resumen: las revisiones no se “enlazan directamente” a los directorios que las contienen (como ocurre con los “sistemas de rutas de ramas”) como TFS, Perforce, Subversion, etc) sino que el sistema tiene que resolver cuándo una revisión depende del selector.
¿Significa esto que la misma revisión de un fichero podría incluirse en diferentes ubicaciones con sólo cambiar el selector? ¡Si, eso es exactamente lo que significa!
El mecanismo es extremadamente potente, pero como contrapartida no es especialmente fácil de implementar. A cambio obtienes renombrado real y muchas otras posibilidades, pero el sistema tiene que realizar una búsqueda para calcular dónde está localizado cada elemento.
La versión de Plastic BL064 tiene un nuevo mecanismo para resolver el selector que supone una importante mejora respecto al anterior. Ahora no solo es rápida la operación de "obtener todo" , sino también el detectar qué se tiene que cambiar si alguien realizó un cambio en la rama en la que está trabajando. El nuevo sistema es muchísimo más rápido.
-
“¿BL064? ¿De qué estais hablando? Acabáis de sacar Plastic 1.5 hace unas semanas…-Puedo oír como algunos os quejareis … :-)
Nosotros utilizamos un esquema de numeración de desarrollo interna (que también está disponible en la versión externa, podéis echar un vistazo a la información de cada versión de los ejecutables), por lo que nuestra versión 1.5 es realmente la BL063. Pero en este momento estamos utilizando la BL065 internamente como soporte de nuestro desarrollo. Así que me temo que las mejoras de las que estoy hablando aún no están disponible, un poco de paciencia…
Estaba muy satisfecho con el nuevo sistema del selector, pero de repente me acordé de GIT…Pensábamos que éramos lo más rápidos en las actualizaciones pero probé GIT y…bueno, pues es una herramienta fea y tonta :-), pero es muy rápida…
Así que instale de nuevo GIT 1.5.2.4 en nuestro Linux FC4, que tiene un par de Intel(R) Xeon(TM) CPU 3.00GHz. Tiene más de dos años pero va bastante rápido.
$ uname -aLinux juno 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT 2005 i686 i686 i386 GNU/Linux.
Importé una versión de nuestro código en un repositorio de git. Quité todos los ficheros locales (¡menos el subdirectorio .git, claro!) e hice un “git checkout .” que recrea todos los ficheros. Tardó unos 20s…
Después probó el mismo escenario con Plastic (BL065).
Tardó unos 29s. Si, GIT es más rápido pero… el servidor de Plastic se reinstaló, con lo que todo el contenido se descargó a través de nuestra red local de 100Mbps!!!
Para poner mayor dramatismo tengo que decir que la prueba se realizó contra nuestro servidor real que no solo tiene una copia del repositorio (como en el caso de GIT) sino de todo el desarrollo, pero no habría habido gran diferencia si el servidor tuviera sólo una copia ya que el tamaño no afecta al rendimiento.
La mala noticia (para mi) es que repetí la operación en git (después de haber quitado todo) y tardó solamente 8s. No se exactamente el motivo (¿cachés en disco?) pero si lanzo el “rm –rf *” justo antes de lanzar el “git checkout .” tarda mucho más que si dejo cierto tiempo entre ambas operaciones. Plastic tiene un rendimiento homogéneo de entre 28 y 30 segundos, no se ve afectado por la operación de borrado.
“Vale, pero ¿qué pasa cuando el servidor de Plastic está instalado en la mismo máquina que el cliente? ¿No sería un escenario más real y daría un rendimiento incluso mejor?", podríais preguntar...
Me temo que si queréis conocer la respuesta tendréis que esperar al siguiente capítulo … :-)
0 comentarios:
Publicar un comentario