Journal Où en est la version GNU/Linux de Firefox côté performances ?

Où-qu'on-en-est côté performances sous GNU/Linux avec Firefox  ?

Vous l'avez peut-être remarqué (mais peut-être pas), différentes fonctionnalités sont dans les tuyaux tandis que certaines sont déjà activées – mais à un rythme différent selon les systèmes d'exploitation.

D'où l'idée de faire le point sur ce qui est déjà implémenté et activé, déjà implémenté mais pas activé, ou pas encore implémenté…

Je me concentrerai donc sur la version desktop pour GNU/Linux dans ce journal un peu expéditif sur la forme, mais assez documenté sur le fond.

État de quelques fonctionnalités

• Basic (c-a-d basé sur xrender) OMTC est activé par défaut sous GNU/Linux depuis Firefox 40 [1]. Vérifier dans about:config que "layers.offmainthreadcomposition.enabled" est réglé sur "true", ou consulter l'écran des informations de dépannage.
  En complément, vérifier que asynchronous panning and zooming (APZ) est activé, de même que les animations CSS (transform, opacity) (régler respectivement "layers.async-pan-zoom.enabled" et "layers.offmainthreadcomposition.async-animations" sur "true" le cas échéant).
  NB : OMTC pour les animations CSS est activé par défaut depuis Firefox 41 (cf http://dbaron.org/log/20150916-compositor-animations). OMTC pour APZ nécessite d'activer le mode multi-processus parallèlement (lire ci-après, et cf https://staktrace.com/spout/entry.php?id=834).

• GL-accelerated OMTC doit être activé à la main (régler "layers.acceleration.force-enabled" sur "true") tant que [2] n'est pas réglé.

• À noter que Firefox 46 utilisera GTK+3 par défaut [3] – toutefois, dans about:buildconfig, chercher l'argument "--enable-default-toolkit=cairo-gtk3" pour savoir si la version de Firefox compilée par votre distribution roule la version 3 de GTK+ – ce qui permettra de changer de bibliothèque d'affichage sans pénalité de performance (historiquement la version GNU/Linux utilise Cairo, mais Skia – déjà utilisé par Firefox sur d'autres plateformes – est une alternative) (dans about:config, chercher "gfx.canvas.azure.backends" et "gfx.content.azure.backends", ou consulter l'écran des informations de dépannage) [4], et nous rapprochera d'une version de Firefox pour Wayland [5].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=722012
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=594876
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1186003
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1038800
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=635134

NB : Toutes les infos dans (et sous) ce billet : https://mozillagfx.wordpress.com/2015/05/19/off-main-thread-compositing-on-linux/

• Tout cela sans parler du mode multi-processus (projet e10s, alias Electrolysis), à activer dans les préférences du logiciel (sous l'onglet Général, rubrique Démarrage). Précédemment j'avais dû y renoncer, mais avec Iceweasel 46.0a2 sous Debian Sid 64 bits cela semble utilisable.

Comparatifs des performances du mode multi-processus

• Le mode multi-processus demande sensiblement moins de RAM sous GNU/Linux que sous Win et Mac (comparer la ligne TabsOpenSettled ici) : 448-872 Mio côté GNU/Linux, 625-1338 Mio côté Windows et 876-1632 Mio côté OS X…

• Firefox en mode multi-processus consomme sensiblement moins de RAM que Chrome : dans ce test (fait par un mozillien), sous GNU/Linux on parle de 525 vs 944 Mio, sous Windows on parle de 512 vs 1,132 Mio, et sous OS X on parle de 1,065 Mio vs 1,354 Mio.

Voili voilou.