Noticias

¿Cómo estamos mejorando el rendimiento de Firefox Snap? Parte 2

Foto de John Anvik, Unsplash

Bienvenido a la Parte 2 de nuestra investigación sobre el rendimiento instantáneo de Firefox. Para minimizar la duplicación, recomendamos revisar Parte 1 de esta serie Allí encontrará un resumen de nuestro enfoque, un glosario de términos y consejos sobre evaluación comparativa estandarizada.

¡Bienvenidos de nuevo, fanáticos de Firefox! Es hora de otra actualización de nuestras mejoras instantáneas de Firefox.

El complemento de Firefox ofrece una serie de beneficios para los usuarios diarios de Ubuntu, así como una gama de otras distribuciones de Linux. Mejora la seguridad, brinda compatibilidad entre versiones y acorta el tiempo para que las mejoras de Mozilla lleguen a manos de los usuarios.

Actualmente, este enfoque tiene ventajas y desventajas en lo que respecta al rendimiento, sobre todo en el primer lanzamiento de Firefox después de reiniciar el sistema. Esta serie realiza un seguimiento de nuestro progreso en la mejora de los tiempos de inicio para garantizar que ofrecemos la mejor experiencia de usuario posible.

En el camino, también abordaremos problemas de casos de uso específicos que se han identificado con la ayuda de la comunidad.

¡Echemos un vistazo a lo que hemos estado haciendo!

Áreas actuales de enfoque

Aquí cubrimos correcciones recientes, áreas de interés recientemente identificadas y una actualización de nuestras investigaciones de perfiles.

Compatibilidad con Jupyter Notebook: CORREGIDO

Sigue el problema

Para varios científicos de datos, la compatibilidad con Jupyter Notebook en el navegador es fundamental para su flujo de trabajo. Al iniciar un cuaderno, hay dos formas de verlo:

  • Abriendo un archivo en ~/.local/share/jupyter/…
  • Navegando a un http://servidorlocal/ URL

La segunda ruta es más compatible con entornos de espacio aislado y no tiene problemas en el complemento de Firefox. Sin embargo, la recomendación predeterminada es abrir el archivo directamente. Esto causó problemas ya que .local no es accesible para las instantáneas confinadas, que limitan el acceso a los directorios de puntos de forma predeterminada.

Hemos fusionado una solución alternativa de snapd que le da acceso a la interfaz del navegador específicamente a ~/.local/share/jupyter para habilitar el flujo de trabajo predeterminado. También informamos el problema aguas arriba y sugerimos cambiar el texto de ayuda para señalar el http://servidorlocal/ URL primero como el viaje de usuario recomendado.

Representación de software

Sigue el problema

La última vez, hablamos de que Firefox no pudo determinar qué controlador de GPU debería usar. En esta circunstancia, recurre a la representación de software en dispositivos como Raspberry Pi, lo que afecta significativamente el rendimiento. Para abordar esto, hemos actualizado la interfaz Snapd OpenGL para permitir el acceso a más ID de PCI, incluidas las que se usan en Rasberry Pi.

Sin embargo, esta solución no parece resolver completamente el problema. Todavía hay informes de aceleración bloqueada por la plataforma. Resolver esto tiene el potencial de marcar una gran diferencia en Raspberry Pi, por lo que continuamos investigando.

Manejo de extensiones

Sigue el problema

Copiar la gran cantidad de paquetes de idioma durante el primer inicio de Firefox sigue siendo un problema constante en todos nuestros puntos de referencia.

Mozilla tiene la intención de reflejar un cambio en el complemento que hicieron en la versión de Windows de Firefox. Esto agregaría la capacidad de cargar solo una configuración regional a la vez en función de la configuración regional del sistema.

Soporte de mensajería nativo

Sigue el problema

La compatibilidad con mensajería nativa habilita funciones clave como dispositivos 2FA y extensiones de GNOME. El nuevo XDG Desktop Portal ha aterrizado en Jammy, pero la integración de Firefox continúa repitiéndose. Las cosas están progresando bien y la solución debería aterrizar pronto.

Soportes de red

Sigue el problema

Firefox snap y flatpak actualmente no pueden interactuar con recursos compartidos de red. Este problema tiene que ver con el XDG Desktop Portal que funciona en modo local. El hecho de que el portal del selector de archivos incluya esos montajes en la barra lateral también aumenta la confusión.

Hasta que se resuelva el problema del portal, una solución consiste en acceder a la montura a través de /var/run/usuario/IDUSUARIO/gvfs (NOTA: necesita instalar gvfs-fuse, que crea puntos de montaje locales).

Manejo de fuentes e íconos

Los nuevos puntos de referencia para el manejo de fuentes e íconos en amd64 sugieren que la creación de caché de íconos, temas y fuentes es relativamente menor en lo que respecta al uso de recursos. Firefox pasa algún tiempo haciendo esto, mientras que Chromium no. Para la mayoría de los sistemas, esto es alrededor de 300 ms, pero en Raspberry Pi el impacto es mucho mayor (hasta 6-7 segundos).

Las investigaciones muestran que el proceso de almacenamiento en caché es muy intensivo en E/S, y la E/S es mucho más lenta en una tarjeta SD con una CPU Raspberry Pi 4.

Este es probablemente un síntoma de un problema subyacente que estamos trabajando para identificar.

Futex () tiempo de llamada al sistema

Analizamos el comportamiento de la instantánea confinada de Firefox frente a la versión no confinada, así como la configuración de Firefox confinada desde el tarball (disponible como descarga directa desde el sitio de Mozilla).

Con la versión limitada, en los resúmenes de ejecución de strace, notamos que la llamada al sistema futex() tarda aproximadamente 20000us en completarse en promedio en Kubuntu 22.04 y aproximadamente 7000us en Fedora 36, ​​ambos instalados en hardware idéntico. Estos números indican contención de bloqueo de memoria, especialmente cuando se comparan con los mismos resultados recopilados de las versiones no confinadas o no instantáneas de Firefox. Allí, la llamada al sistema futex() promedia solo alrededor de 20us

Además, notamos que la versión instantánea ejecuta muchas más llamadas al sistema futex() (así como otras). Se espera algo de esto, ya que la ejecución de la instantánea difiere de las aplicaciones que no son instantáneas, incluido el uso de instantáneas base y de contenido, así como el confinamiento de seguridad.

El problema se ha informado constantemente en diferentes plataformas de hardware y distribuciones de Linux, con el tiempo promedio general de llamada al sistema futex() correlacionado linealmente con el tiempo de inicio observado.

Por ejemplo, un resumen de seguimiento de muestra (trazo -c) de una ejecución instantánea de Firefox:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- -------------------
 82.18  388.576521       18131     21431      2272 futex
 10.31   48.737839        7583      6427         4 poll
  4.09   19.350524        7660      2526         6 epoll_wait
  1.50    7.114924       72601        98        38 wait4
  0.69    3.258415         574      5676      2715 recvmsg
  0.51    2.406544       41492        58           clock_nanosleep
  0.13    0.633050          71      8843         5 read
  0.12    0.564651          34     16452     11403 openat

Y en comparación, la versión tar en el mismo host:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- -------------------
 46.13    0.397783           8     47957           clock_gettime
 19.76    0.170379          21      7828      1245 futex
  6.90    0.059470           8      6888           gettimeofday
  5.22    0.044991           8      5353      4324 recvmsg
  3.49    0.030111           8      3745           poll
  2.57    0.022125       22125         1           wait4
  1.75    0.015092           8      1829           read
  1.68    0.014518          15       942       319 openat

Hemos observado resultados similares con otras instantáneas, incluidas Thunderbird y Chromium. Si bien el tiempo de inicio real difiere de un ajuste a otro, el comportamiento general es consistente y subraya un exceso de cálculo con los binarios de ajuste.

Intentamos aislar la fuente de este fenómeno de diferentes maneras. Primero, tratamos de entender si el confinamiento de seguridad puede ser la causa de cualquier conflicto en la administración de la memoria que podría causar que Firefox (y otros archivos binarios) experimenten problemas de bloqueo del espacio de usuario. Esto se traduciría entonces en un exceso de llamadas al sistema futex() y su subsiguiente tiempo muy alto por llamada. Deshabilitar el confinamiento de AppArmor y Seccomp no produjo ninguna mejora.

Del mismo modo, compilamos Firefox con su sandboxing interno deshabilitado, así como también compilamos el navegador con el uso de tmalloc (para comprender si puede haber otras razones para la contención de la memoria), pero estos intentos tampoco generaron mejoras en el tiempo de inicio.

Continuamos explorando este problema con más controles de seguimiento y memoria en una versión de snapd no confinada.

Mantenerse en contacto

¡Eso es todo por la actualización de esta semana! Esté atento a la Parte 3 en las próximas semanas. Mientras tanto, no olvide estar atento a nuestros principales agregadores de problemas y comentarios:

Si desea tomar puntos de referencia y realizar un seguimiento de las mejoras en su propia máquina, no olvide leer nuestra sección «Cree sus propios puntos de referencia» en la Parte 1 de esta serie y compártalos en nuestro tema Discurso.

LEER  Lanzamiento de Wayland 1.21 Alpha

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba