Le projet Electrolysis vise à isoler plusieurs processus dans Firefox pour augmenter ses performances et sa sécurité. Un travail en cours depuis plusieurs années, mais seulement disponible dans le canal Developer. Firefox 48 marquera un premier vrai pas de cette technologie vers le grand public.
Electrolysis est presque considéré comme une arlésienne par les aficionados de Firefox : évoquée depuis des années, la technologie n’a jamais été diffusée auprès des utilisateurs. Son absence se fait d’autant plus remarquer que le navigateur est actuellement le seul à garder une structure monolithique, dans laquelle un seul processus s’occupe de l’ensemble des opérations. Chrome et Edge, par exemple, isolent chaque onglet dans un processus séparé.
Un travail de longue haleine
Cette approche multiprocessus a principalement deux avantages et un défaut. D’abord, elle augmente la sécurité générale en interdisant certaines opérations par les sites. Chaque onglet ayant son propre espace mémoire isolé, certains mécanismes deviennent impossibles à exploiter. Sous réserve bien entendu qu’une faille ne permette pas de contourner cette isolation. Ensuite, les processus multiples tirent mieux parti des cœurs d’exécution du processeur. Le plantage d’un onglet ne doit pas entrainer le reste du navigateur dans la chute. Cependant, l’ensemble se fait au détriment de la consommation de mémoire vive, qui augmente mécaniquement.
Mais Firefox a été conçu comme un programme monolithique. Changer de telles fondations casse logiquement le fonctionnement profond du navigateur. Voilà pourquoi Mozilla a pris son temps jusqu’à présent. Electrolysis, baptisé E10S, peut néanmoins se tester depuis plusieurs mois dans l’édition Developer de Firefox, dans lequel il est activé par défaut. Il n’était auparavant disponible que dans une branche séparée de développement, accessible uniquement depuis le serveur FTP de l’éditeur.
Electrolysis chez 1 % des utilisateurs avec Firefox 48
Firefox 48 est la première version à propulser véritablement E10S vers les utilisateurs, la bêta venant tout juste de paraître. Le développeur Asa Dotzler explique dans un billet de blog qu’il s’agira dans tous les cas d’un lancement en deux temps. Firefox 48 n’activera en effet Electrolysis que pour 1 % de la population. Selon Dotzler, cela permettra à Mozilla de doubler le nombre d’utilisateurs qui se serviront d’Electrolysis (en comptant les testeurs habituels).
La suite dépendra des remontées : « Si nous rencontrons des problèmes, nous pouvons ralentir la diffusion, la mettre en pause ou même désactiver E10S pour ceux qui l’ont eu » avertit Asa Dotzler. Cet avertissement souligne un certain inconnu pour Mozilla. L’éditeur sait qu’Electrolysis peut entrainer des problèmes, parmi lesquels des chutes de performances dans certains cas, et surtout une cassure de la compatibilité avec des extensions.
Le développeur confirme en tout cas qu’E10S est certainement le plus gros changement effectué dans Firefox depuis les débuts du navigateur. Idéalement, si tout se passe bien pendant l’utilisation de Firefox 48 (surtout à l’arrivée de la version finale), c’est la mouture 49 qui marquera la généralisation de la technologie. On rappellera en outre que la version finale de Firefox 47 est disponible depuis peu.
Commentaires (90)
#1
Cependant, l’ensemble se fait au détriment de la consommation de mémoire vive, qui augmente mécaniquement.
Aujourd’hui la plupart des machines sont dotées de 4Go de RAM minimum du coup autant les utiliser, c’est pas fait uniquement pour décorer les CM ces bêtes là
A l’heure ou le multicore est devenu la norme même sur mobile, et est là sur desktop pour le grand public depuis plus de 10 ans, ça semble hallucinant qu’un soft de l’importance de Firefox soit toujours monolithique.
#2
“Electrolysis, baptisé E10S, peut néanmoins se tester depuis plusieurs…”
" />
Années, mois, semaines, jours, heures, minutes, secondes, autres ?
#3
montures 49 ,3 versions /icônes
" />
#4
#5
Oh, ça va faire olus d’un an qu’on y a droit dans la Nightly !
#6
Oui, c’est mon problème, et il n’est pas récent. Je relis deux fois mes papiers, et aucune actu de NXI ne va en ligne sans avoir été relue au moins une fois par un autre rédacteur. Mais quand le cerveau se doute du mot qu’il va trouver, il ne voit même pas l’absence. Le tout est de corriger dès que le souci est signalé ;)
#7
On parle de généralisation au grand public là ;)
#8
Certains commente vraiment avant de lire la news
" />
#9
Je dois avoir loupé quelque chose mais comment active-t-on ce multiprocessus ?
" />
Avec FF Dev Edition, c’était directement dans les options…
A mois d’avoir loupé quelque chose…
#10
si ce la fait même après relecture par un autre, c’est quand même embêtant.
#11
Merci pour l’info !
Pour ceux qui veulent activer la fonction, mettre “browser.tabs.remote.autostart” sur “True”.
Je suis à 1Go de RAM, je vais voir comment l’appli se comporte dans le temps…
#12
Pour l’active manuellement! about:config > browser.tabs.remote.autostart to true. After restarting the browser, you can check whether it’s enabled by visiting about:support and checking that “Multiprocess Windows” = 1. (source:Ars Technica UK)
#13
Y a tjs le fouet après ….cela remet en place les mauvais réflexe ,non ? ^^
#14
Je suis concerné par ce défaut de relecture qui m’a valu des années de zéro en dictée.
Courage!!
#15
#16
ouep.
Après, le délai est normal car E10S était loin d’être stable …
Alors que là, depuis qques mois ,je n’ai plus eu de crash ou onglet planté.
#17
#18
Pour les affolés du mulot, la dernière béta 48 win_64 date d’hier
" />
https://download-installer.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-be…
#19
#20
Oups, je me suis lancé avec la béta … ça vaut la peine. Je ne pense pas réellement un effet placebo : il y a vraiment un gain de vitesse de téléchargement, surtout si on envoie plusieurs onglets avec tout un tas d’images dans chaque onglet.
#21
Cependant, l’ensemble se fait au détriment de la consommation de mémoire vive, qui augmente mécaniquement.
Mais est ce que la mémoire est correctement libéré après la fermeture des onglets?
Actuellement après quelque jours sans redémarrer firefox, il manger plusieurs GB, même si il me reste que 5 onglets ouvert.
#22
ça c’est le boulot de l’OS d’allouer les ressources.
#23
#24
#25
C’est pas l’OS qui dit à Chrome de bouffer toute la RAM avec 50 processus.
#26
Je me pose du point de vue de l’utilisateur, d’autant que je ne suis pas développeur et n’ait aucune connaissance de l’allocation mémoire aux process par Windows.
Pourquoi Firefox avec 10 onglets consomme 1.4Go de mémoire vive et Chrome avec 5 onglets 3.4Go au cumul de ses process ?
Sur les 6Go de la bécane.
Pour moi il y a un défaut de conception quelque part quand un onglet avec Gmail bouffe plus de RAM qu’Outlook. (et donc rajouter la conso de l’onglet Agenda, etc)
Et devant subir en entreprise cette mode de tout foutre chez les voleurs de données…. Pas le choix d’utiliser autre chose que le client Google sur le PC.
#27
Firefox avec e10s consomera environ 25% de RAM en plus (c’est la limite maximum que s’est fixé l’équipe dapres le wiki du projet)
#28
Certains onglets sont de gros consommateur, gmail est horrible pour ca (et peut importe le navigateur).
#29
“Fenêtres multi-processus 0/1 (Désactivé par des modules complémentaires)”
" />
#30
#31
Et sinon la restauration des sessions comme sous FF42 c’est toujours pas à l’ordre du jour ?
#32
Que cherches-tu exactement ? Si c’est pour rouvrir une session précédente, c’est « Historique – Restaurer la session précédente ». Si c’est pour la demande d’enregistrer les onglets à la fermeture du navigateur, c’est « about:config – browser.showQuitWarning -> true ».
#33
Pour les aventureux sur nightly, il y a aussi dom.ipc.processCount qui permet de régler le nombre de process WebContent qui tournent. Par défaut, même avec e10s ça reste un pour le moment. Donc un tab qui crash emporte tout le monde. Il y a des choses pétées quand on utilise une valeur supérieure à 1 pour cette pref (la page view-source par exemple de mémoire), mais globalement je suis sur nightly avec e10s activé et dom.ipc.processCount à 12 et ça tourne plutôt très bien !
Mais attention, ça reste à conseiller aux personnes qui se sentent de rapporter des bugs.
#34
C’est ce que je fais. Mais on est souvent pris par le temps.
#35
Ça ressemble àhttps://bugzilla.mozilla.org/show_bug.cgi?id=1100840 est-ce que tu peux aider à collecter des infos ? Merci :)
#36
#37
J’ai la même chose et je ne comprends pas pourquoi.
Je n’arrive pas à voir à cause de quel module.
#38
Le principe de la RAM c’est de l’utiliser
#39
#40
#41
L’OS sait gérer la RAM pour que ça soit fluide avec le maximum d’applications
#42
“Légère augmentation de la consommation mémoire” avec Electrolys, super pour mon pc patate
" />
Question conne : si je doit tuer firefox.exe dans le Gestionnaire des Tâches, je doit en tuer combien maintenant?
Pardon, je veut dire : avec Chrome comment ca fonctionner? Faut tous les tuer un par un? J’imagine qu’avec Firefox cela fera pareil.
Je vais devoir utiliser tskill ou quoi?
Bonjour le binz :)
#43
Et si tu as 4-5 softs gourmants qui utilisent ce principe (utiliser un max de RAM comme si ils étaient seuls) en même temps, l’OS va faire quoi ?
Exemple : Firefox, Chrome, Eclipse & Photoshop…
#44
#45
Si c’est pas trop compliquer et que ça prend pas trop de temps.
#46
Il pagine une partie de la mémoire vive sur ton disque dur/SSD.
#47
#48
Étrange. Je viens de tester avec les cookies désactivés et Firefox (46) sauve la session. Après, je n’ai pas testé ça 100 fois pour vérifier en quelles proportions ça sauverait parfois « très mal » ou « que certains onglets ».
#49
Je ne peux pas m’empêcher d’avoir de grosses craintes pour mon type d’utilisation, avec jamais moins de 100 onglets, souvent bien plus, certes pas tous chargés mais quand même, quand je vois Chrome consommer plus de RAM avec 5 onglets que firefox avec 50…
D’un autre coté, depuis un certain temps, je passe mon temps à relancer Firefox tant il (ou des addons, même si j’en ai viré pas mal et ajouté aucun) sature vite au point de freezer au moindre chargement d’onglet. Ca devrait pas mal améliorer ça, que ce soit l’impact d’un onglet sur le navigateur et les autres onglets ou la libération de RAM à la fermeture d’un onglet.
#50
Donc, ça rame. Surtout avec un disque dur.
#51
Donc 2 visions possibles :
Sachant que tu es plus souvent dans la 2eme situation que dans la 1ere (ne serait-ce qu’avec les anti-virus & cie), et que tu ne sais pas forcément ce que tu va devoir lancer plus tard, il est souvent plus efficace au final que les softs n’abusent pas avec les ressources (que ce soit RAM ou autre…)
#52
Tu tues un seul firefox.exe.
Chrome a son propre gestionnaire de tâches.
#53
Je n’y connais rien en développement de moteur HTML et Javascript, ni même en développement web, mais peut être qu’il est difficile de faire autrement que des processus mémovores à l’heure où la moindre page web va charger 70 images, 12 scripts et une vidéo, avec chaque onglet ayant sa propre pile et son propre tas. En tout cas, je ne m’aviserais pas à prendre les développeurs de Chrome/Webkit et Firefox pour des mauvais.
Après, c’est sûr, n’importe quel système marchera mieux avec plus de RAM qu’avec moins. Mais si t’en as un tant soit peu et que tu n’utilises pas tout tes processus toutes les 5 minutes, le swap n’est pas mortel.
#54
Pareil, j’avais rapidement adopté Chrome pour sa légèreté mais ça c’était avant, aujourd’hui j’ai l’impression que c’est lui le plus lourd de tous et de loin.
" /> (avec Chrome et FF l’image saute, saccade, flashs au noir réguliers, bref inutilisable, vu qu’ils ne communiquent pas sur ce qu’ils ont changé je sais pas ce qu’ils ont foutu mais c’est vraiment pas une réussite)
Jusqu’à maintenant je le gardais uniquement parceque Firefox était incapable de faire tourner correctement l’Eurosport Player mais depuis leur dernière mise à jour le seul navigateur avec lequel ça marche nickel c’est … IE
#55
C’est bien l’OS qui l’autorise à l’utiliser. Ensuite, il y effectivement un soucis de libération de la RAM de la part des navigatieurs
#56
#57
#58
#59
#60
S’ils pouvaient activer l’accélération hardware des vidéos html5 depuis qu’ils sont passés à FFmpeg, ça serait cool… non mais parce qu’on est quand même en 2016 quoi, et faire des régressions de performance, ça va un peu… Je parle pour Linux mais ça m’étonnerait pas que ça soit pareil sous Win.
#61
#62
#63
#64
Disons que sobriété n’est pas tout à fait le bon terme, c’est plutôt une histoire d’impression de légèreté et de réactivité qui frappait sur les 1ères versions en comparaison avec les navigateurs d’alors et c’est cette impression de légèreté qui s’est évanouie au fil des versions alors que dans le même temps les autres navigateurs eux ont fait de gros efforts en la matière.
#65
Pas directement en rapport, mais quelqu’un sait-il comment désactiver cette putain de mise en cache des redirections de mes deux ?
Ras le bol de purger mon histo toutes les 30s pendant que je setup un serveur….
#66
#67
Ça et ça.
En gros, le cache des 301 c’est un comportement prévu dans la norme (redirections définitives). Pour des redirections temporaires, il faut utiliser des 303 ou 307.
#68
#69
Comme le multi-processus est prévu un peu tard pour les utilisateurs [1], j’ai pu expérimenter par curiosité cette fameuse version 48 en développement depuis quelques temps. Comparé au Firefox sans Electrolysis, on sent que l’interface répond un peu mieux.
Mais avec la configuration par défaut, ce Firefox n’apporte pas grand chose. L’empreinte mémoire est toujours aussi catastrophique. En quelques clics, on se retrouve facilement à 1 Go de mémoire inutile non libérable avec “about:memory”. La liste des recommandations [2] est assez peu convaincante.
La seule chose prometteuse est le paramètre “dom.ipc.processCount” dans about:config. Après redémarrage, ça ressemble en effet beaucoup plus au fonctionnement de Chrome. Ça crée bien N processus mais contrairement à Chrome qui ajoutera un processus lourd par onglet, ici ça se fait dans une limite. Avec 4 processus, si vous ouvrez 5 onglets, le dernier sera réalloué sur un des processus déjà lancés. Donc le nombre de processus à définir serait égal au nombre minimal de pages indépendantes nécessaires pour travailler.
Merci beaucoup lissyx pour ton information vraiment très utile ! A voir dans les prochains jours ce que ça donne…
[1]https://wiki.mozilla.org/Electrolysis#Schedule
[2]https://support.mozilla.org/en-US/kb/firefox-uses-too-much-memory-ram
#70
#71
Qu’est-ce que tu appelles 1Go de mémoire non libérable ? C’est peut-être le soucis rapporté danshttps://bugzilla.mozilla.org/show_bug.cgi?id=1100840 ou lié à ça.
![https://nightly.mozfr.org/](https://nightly.mozfr.org/)
Ensuite, “non libérable” faut voir comment tu mesures aussi, les OS peuvent te leurrer des fois … :)
Je suis intrigué parce que j’utilise énormément de tabs, avec e10s et d’autres fonctionnalités activées, et la consommation mémoire est loin d’être délirante. Par contre, certaines pages sont vraiment très consommatrices … :/
Sinon, oui, les processus de contenu (WebContent) sont partagés entre les onglets. Je ne connais pas les plans futurs, mais sur B2G le modèle de processus utilisé fait qu’on a réellement un seul processus dédié par tab, avec un partage des données partageable via NUWA.
Quoi qu’il arrive, tous les retours sont les bons, et plus on aura d’utilisateurs sur Nightly, plus la qualité s’améliorera
#72
Oh et j’oubliait, un nightly avec health report activé ça permet de mieux traquer les soucis :)
#73
#74
#75
#76
Pour la vidéo sous Windows, FIrefox utilise les codecs de Windows dont l’accélération matérielle de H264 quand elle disponible, j’imagine.
Pour l’accélération matériel des autres codecs, VP9 est envisagé dans Windows 10: https://blogs.windows.com/msedgedev/2016/04/18/webm-vp9-and-opus-support-in-micr…
#77
Merci !
" />
Un truc pour le cache des 503 par hasard ?
#78
#79
#80
Oui, c’est bien cela. La consommation est grande surtout avec les sites qui utilisent trop le JavaScript. C’est très marqué avec le nombre de processus égal à 1 par défaut. Mais ça a l’air d’aller mieux avec le nouveau paramètre. A surveiller dans le temps…
#81
idem.
Du coup j’ ai déactivé tous les modules puis redémarré Firefox.
Par contre, avec un programme de copie de fichiers en même temps cela rame horriblement.
Multi taches certes mais mon Core 2 Duo E6700 3,8 Ghz 8 Go Ram ne suis pas.
Un quad core pour exploiter le multi taches me semble du coup indispensable.
#82
https://download-installer.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-beta-l10n/firefox-48.0.fr.win64.installer.exe
#83
C’ est sûr que si tu fais du montage vidéo et que tu n’ as pas posé 32 ou 64 Go de Ram sur ta carte mère tu risques d’ avoir un souci d’ usage alternatif du disque en lieu et place des barrettes qui vont bien.
Bien entendu, cela s’ applique aussi exactement de la même manière dans le cas où plusieurs programmes tournent simultanément.
Mais là c’ est que tu as plutôt un problème d’ information à l’ achat du matériel qu’ un problème de “swap”.
Je ne sais pas comment fonctionne l’ allocation mémoire vive sur d’ autres systèmes que Windows mais pour ce qui concerne Windows x64 la question n’ a aucun sens puisque Windows 7 pro et au dessus gère sans souci jusqu’ à 192 Go de mémoire vive.
Donc aucun souci si tu t’ es donné la peine de passer à la caisse et d’ acheter ce qui va bien.
Ce qui revient à te poser la question : pourquoi activer l’ usage du disque comme mémoire alternative aux barrettes quand le disque est vraiment le pire goulot d’ étranglement des performances ????
La mémoire ce n’ est pas cher et c’ est carrément une autre planète de performance plutôt que radiner sur les barrettes de mémoire vive qui vont bien.
D’ autant qu’ avec de bonnes grosses barrettes, tu peux créer un disque de mémoire vive qui laisse à des kilomètres derrière n’ importe quel SSD PCI-Express pour la moitié du prix ????
Perso, j’ interdis à Windows l’ usage de quelque façon que ce soit l’ usage de mémoire tampon sur le disque.
Et je n’ ai jamais au grand jamais eu un quelconque souci quel qu’ il soit.
Le seul processus que ne peux gérer Windows sans user de tampon mémoire disque est le scan minutieux de celui ci pour trouver et réparer les défauts et secteurs morts.
Pour des hdd. Je n’ ai pas testé sur des ssd.
Là le système tombe faute de mémoire vive et tu vois les limites d’ une politique de refus d’ usage d’ un tampon disque en remplacement de mémoire vive. Sinon WTF !!!!!!
#84
Les clients te choisissent mais toi aussi tu peux choisir tes clients.
Apple fais très bien cela avec des téléphones à 1 000 €.
Donc pas pour tout le monde …
Et même l’ épicier du coin avec des clients qui l’ emmerdent ….
C’ est pour cela que certains clients sont gâtés et d’ autres beaucoup moins côté services ou tarifs ….
Cela s’ appelle du commerce.
Mais pour ceux qui ne comprennent rien à cette règle, on a un moyen efficace de gagner des ous sur leur pomme ET en plus de s’ en débarasser ….
Je rigole toujours quand des gens se croient tout permis dans un commerce.
Ils se tirent eux mêmes tout seuls une balle dans le pied sans rien y comprendre.
Tu laisses les mauvais clients qui coutent cher en termes de support sans rapporter des masses à tes concurrents et tu gardes ceux qui te permettent d’ économiser des sous de ce côté …
#85
#86
#87
C’est pas parce que c’est une structure monolithique que ca ne tire pas parti de l’architecture multi-coeur des processeurs modernes.
Firefox utilise bien des threads pour paralleliser ses onglets, mais tout cela reste contenu dans un seul processus.
Tu peux le verifier facilement en lancant “Process Explorer” (gestionnaire des taches ameliore), qui affiche le nombre de thread utilise par chaque processus.
Electrolysis ne va pas apporter de gain de performance mais simplement plus de resistance au crash lorsqu’un onglet plante, puisque seul le processus en question s’eteindra.