Después de estos años trabajando con PHP, una cosa queda clara: a partir de un cierto punto, el uso de memoria y de CPU son elementos limitadores en el rendimiento de nuestras aplicaciones. Con el tiempo y la introducción de frameworks de desarrollo, el consumo de recursos se incrementa notablemente, y aunque el coste de la RAM se ha reducido, esto no es un argumento aceptable: si hay lenguajes más eficientes acabarán siendo los preferidos, especialmente en un momento en el que los buscadores exigen el mínimo tiempo de respuesta.
Aunque el objetivo no es nuevo (APC, eAccelerator y el Zend Engine van en una dirección similar), la aproximación en aquel momento fue diferente: HipHop convertía el código en C++ (para luego compilarlo), no en opcode (para luego ejecutarlo sobre el propio motor de PHP).
Esta mejora en la ejecución tampoco redundaba en mejoras de velocidad para otras operaciones, como por ejemplo consultas de la base de datos: si el cuello de botella de una aplicación estaba en ese punto, el resultado final no mejoraría significativamente. Aún así, la promesa de un PHP más eficiente en el uso de la CPU y de la memoria era generar unas altas expectativas. Desde entonces el proyecto ha ido evolucionando sin mucho ruido, y quizá debido a sus limitaciones, la implantación no fue extensiva.
Sin embargo el proceso de HHVM es diferente al de HipHop. En el caso de HHVM, se convierte PHP a un bytecode que luego es convertido a lenguaje máquina con un compilador JIT. Este procedimiento es similar al utilizado por la Máquina Virtual de Java, por ejemplo. Este cambio evita el proceso de compilación que sí requería HipHop, por lo que el proceso de actualización de código resulta más ágil con HHVM. Algunas de las ideas son similares a APC, pero desde luego el proceso no es el mismo. APC es un componente que se puede instalar aparte, y HHVM es la base sobre la que corre PHP.
Con el tiempo, la carrera se ha encaminado a tener una herramienta de aplicación en un espectro lo suficientemente amplio de frameworks y aplicaciones populares que asegure su difusión. Sin ir más lejos, actualmente no parece posible configurar HHVM para que utilice Apache, aunque está en su Roadmap.
En esa dirección, el pasado 19 de Diciembre se publicaba en el blog de HHVM un artículo sobre la ejecución de pruebas unitarias de diversos frameworks en HHVM. Desde el inicio de esas pruebas hasta el resultado final, la mejora ha sido notable en algunos casos (Symfony o Yii por poner dos casos populares), con una media de un 9.62% de la superación de pruebas unitarias, y una mejora del 16% del rendimiento (ojo, sobre la ejecución de la base de código de facebook.com).
En resumen, HHVM es a mi modo de ver un proyecto que hay que seguir de cerca. En un momento en el que PHP-FIG trabaja a fondo en las PSR y que el uso de frameworks es indiscutible para el desarrollo de aplicaciones web medianamente escalables, HHVM puede ayudar a dar el paso para superar los problemas de rendimiento de un lenguaje que no fue originalmente concebido para este enfoque.
He encontrado este artículo sobre las implicaciones del uso de HHVM, interesante lectura.
© 2007 and beyond Mario Alberich, licensed under CC-BY-SA unless stated otherwise.