GNOME Shell en un entorno con grandes virtudes, pero que tiene un gran talón de aquiles en el rendimiento. Esto es algo que saben en Canonical y sobre todo Daniel Van Vugt, uno de los desarrolladores del escritorio Ubuntu, que destaca por sus contribuciones para mejorar el desempeño de GNOME.

En una entrada publicada hace poco en el sitio discourse de Ubuntu, Daniel Van Vugt expone los problemas que tiene GNOME a nivel de rendimiento, el principal origen de estos y los planes de la distribución para mejorar en ese sentido. Además, pone sobre la mesa dos de las quejas más extendidas: lo lento que va GNOME en máquinas antiguas o poco potentes y el lag que se puede apreciar incluso en ordenadores de gama alta.

Van Vugt explica que el origen de los problemas de rendimiento no está en el entorno en sí, sino en Mutter, que incluye los tookits gráficos Clutter y Cogl. Mutter es un compositor que puede ser usado de manera separada de GNOME Shell, siendo la verdadera parte grande del asunto. Sí, para muchos puede resultar sorprendente, pero GNOME Shell es la parte “pequeña”, ya que el entorno de escritorio se dedica a usar los componentes de Mutter a modo de bibliotecas.

En lo que se refiere a la cantidad de código, GNOME Shell se compone de 199 ficheros de código en C y 157 ficheros de código en JavaScript. Esto podría hacer pensar que hay cierto equilibrio en el uso de las dos tecnologías, pero si a eso le sumamos que Mutter está compuesto 1.389 ficheros en C, nos encontramos con que el 90% del conjunto completo está construido con C, frente a tan solo un 10% de JavaScript. ¿Sorprendido? Este servidor no va a negar que se esperaba que el porcentaje de JavaScript en GNOME Shell fuese bastante superior.

La conclusión es que, si bien los usuarios tienden a echarle la culpa a JavaScript por el hecho de ser un lenguaje interpretado, el verdadero origen del problema está en el código en C de Mutter. Van Vugt explica que “en el caso de Gnome Shell, sus mayores problemas de rendimiento en los últimos tiempos no fueron puntos críticos. Se representaron mejor como puntos fríos que estaban inactivos en lugar de actualizar la pantalla sin problemas. Tales puntos fríos solo son aparentes cuando se observa el uso en tiempo real de un programa, y no en el tiempo de CPU o GPU consumido”. Estas palabras fueron dichas en referencia a que los desarrolladores tienden a buscar la solución de los problemas centrándose en el uso de la GPU y la CPU, pero el origen, al menos desde su punto de vista, no está ahí, sino en el código de Mutter.

“Gnome Shell y Mutter son aplicaciones de bucle de eventos Glib de un solo subproceso (un único hilo). Por lo tanto, cualquier pausa podría hacer que se pierda el siguiente cuadro y se exhiba stuttering. Algunas pausas comunes son para entradas y salidas de disco o GPU, pero calcular mal cuándo representar la siguiente imagen también ha sido un problema en GNOME Shell.”

En GNOME 3.34 se han corregido una gran cantidad de fallos en “tiempo real”, que son los originarios de que se aprecien saltos anómalos de fotogramas en el entorno, sin embargo, todavía quedan otros problemas por resolver, como el renderizado de Wayland en configuraciones multimonitor y el programador de imágenes de Mutter en algunos casos específicos.

La intención del desarrollador que forma parte del escritorio Ubuntu es que los dos fallos mencionados en el párrafo anterior sean resueltos para Ubuntu 20.04, abriendo la puerta a mejorar el desempeño en ordenadores de alto rendimiento con GNOME 3.36. Tras lograr dicho objetivo, lo siguiente será conseguir en posteriores versiones de Ubuntu que el sistema sea capaz de ofrecer una experiencia fluida en ordenadores antiguos y/o lentos, aunque reconocen que esto último es más difícil de lograr, de ahí que la intención sea que llegue en Ubuntu 20.10.

¿Y tú, esperabas que los problemas de GNOME derivaban de usar JavaScript?