Composer mejora su rendimiento un 100% gracias a las micro-optimizaciones de código
Composer es el proyecto que más impacto ha tenido en la comunidad PHP en los últimos años. Aunque originalmente se creó para mejorar la instalación del framework Symfony, rápidamente se extendió su uso para gestionar las dependencias de cualquier proyecto PHP.
Hoy en día es imposible pensar en crear un proyecto PHP que no utilice Composer, a pesar de su gran defecto: una lentitud extrema. No es extraño tener que esperar hasta varios minutos cuando quieres actualizar las dependencias de un proyecto complejo, lo cual llega a ser desesperante.
La razón oficial de su lentitud siempre había sido que resolver las dependencias de una aplicación es un problema muy complejo de resolver desde el punto de vista matemático. Y aunque por supuesto lo es, algunos pensábamos que no podía ser tan complejo como para ser tan lento.
Jordi Boggiano, uno de los dos creadores originales de Composer, acaba de publicar el siguiente tweet:
Between some optimizations from @naderman and a tip by @schmittjoh about gc_disable, Composer now runs in ~half the time it did yesterday!
En otras palabras, gracias a unas pequeñas micro-optimizaciones en su código, Composer ahora es el doble de rápido. Los primeros datos que los usuarios han publicado en Twitter lo confirman: @SteveEdson ha mejorado de 7.5 a 3.5 segundos; @falc ha mejorado de 84.81 a 27.49 segundos; @lsmith ha mejorado para Symfony CMF de 176 a 9 segundos.
¿Y cuáles son esas micro-optimizaciones? Son tan simples que parece increíble que hayan mejorado Composer tanto:
- Se ha añadido una llamada a la función que deshabilita el recolector de basura (Disable GC when computing deps). Esta es, con mucha diferencia, la optimización que ha proporcionado una mayor mejora.
- Se ha eliminado un getter y se ha transformado en una propiedad pública (esto ahorra unas 500.000 llamadas a funciones) (Make ruleById lookup table in rule set public).
- Se ha eliminado otro getter y se ha transformado en una propiedad pública (esto ahorra más de 1.3 millones de llamadas a funciones) (Make project id public)
- Se han eliminado muchos checks innecesarios para los arrays (Remove further unnecessary checks for packages being arrays)
El caso de Composer demuestra que las (micro) optimizaciones de código son muy importantes, incluso para proyectos PHP. Añadir estas optimizaciones mientras se desarrolla la aplicación es una pérdida de tiempo, pero no hacerlo cuando la aplicación ya está terminada, es totalmente irresponsable.
¿Cómo saber dónde tienes que micro-optimizar tu código? Nunca deberías tratar de adivinar cómo mejorar el rendimiento y nunca deberías seguir ciegamente las técnicas que han empleado otros proyectos. Así que si después de leer este artículo crees que tu aplicación será mucho más rápida si eliminas los getters, estás equivocado ... o quizás no. La respuesta solamente la tienen los profilers, que te indicarán cuáles son las partes más lentas de tu aplicación. Estos son algunos de los mejores profilers disponibles para aplicaciones PHP: Xdebug, uProfiler, Qafoo Profiler o Blackfire.
Actualización 2-dic-2014: a medida que se van reportando más comparativas entre el viejo y el nuevo Composer, tenemos una medida más aproximada de las ganancias. Dejando a un lado los casos extremos, la mejoría conseguida por el nuevo Composer se encuentra entre un 30% y un 90%, sin que hasta el momento se haya reportado ningún error de importancia. El consumo de memoria permanece muy estable entre las dos versiones de Composer.
(Disclaimer: Blackfire está desarrollado por SensioLabs, empresa para la que actualmente trabajo)
Comentarios
Este artículo ya no permite añadir más comentarios.
¿Por qué? Los artículos cierran sus comentarios automáticamente
unos meses después de su publicación para asegurar que estos sigan
siendo relevantes.
Proyectos Symfony destacados
La forma más sencilla de generar el backend de tus aplicaciones Symfony. Ver más
Síguenos en @symfony_es para acceder a las últimas noticias.