22 novembre 2007

Firefox (et Flock) et la consommation mémoire

En réponse à un commentaire à mon blog dans un billet sans relation avec Flock...


je suis allé sur le site recommandé dans le commentaire de Rod sur le même post sur Tech Crunch, donc je rementionne le lien :
http://www.korben.info/enfin-un-truc-pour-eviter-la-surcharge-memoire-avec-firefox.html

Il y a un espagnol qui a fait un utilitaire simple et efficace pour ENFIN réduire la consommation mémoire de Firefox.

=> l'algorithme en C est même communiqué
=> seul truc qui refroidi il a ajouté un bout dans son code qui va sur son site pour suggerer une "donation' paypal.

Il suffirait qu'un développeur intègre l'économiseur de mémoire à Firefox pour faire disparaitre sa tare majeure

Ce n'est pas la première fois qu'on m'en parle et qu'on me demande si Flock ou Firefox allait intégrer cela. La réponse est non, et la raison est que cet "utilitaire" ne résout rien du tout. Enfin si, ça résout un problème : ça rassure les maniques du Gestionnaire de Tâches de Windows.

Pourquoi Firefox consomme tant de mémoire?

Chaque octet utilisé l'est pour l'une de ces deux raisons:
  • La mémoire utilisée légitimement. Tout programme a besoin de mémoire, mais ce qui cause la gourmandise de Firefox est surtout (1) la plateforme et (2) son cache. Firefox garde les images récemment visitées ainsi que le rendu des pages en cache pour un chargement plus rapide.
  • Les fameuses "fuites de mémoire": avoir des fuites de mémoire signifie que de l'espace mémoire non utilisé est anormalement gardé par le programme. En gros, à cause d'un bug dans le code, le programme pense que l'espace est toujours nécessaire à son fonctionnement alors que ce n'est pas le cas. Le problème inverse consiste à libérer à tort de la mémoire toujours utilisée, et ça conduit à un crash pur et simple.

Comment réduire l'utilisation mémoire de Firefox?

On peut agir sur la mémoire utilisée légitimement, par exemple en réduisant le cache mémoire dans les préférences. Firefox sera plus lent, parce qu'il devra à chaque fois charger son cache depuis le disque. On peut aussi désactiver le bfCache (back-forward cache), qui garde un rendu de la page en cache. Grâce au bfCache, quand vous cliquer sur le bouton "back", la page précédente s'affiche instantanément.

Comme vous le voyez, réduire l'utilisation mémoire a toujours un cout, en général en terme de performances. Soit vous voulez un logiciel rapide, soit un logiciel qui utilise peu de mémoire.

Parlons maintenant des fuites de mémoires. Quand on en trouve, on les corrige ! Que ce soit Mozilla ou Flock, on perd jamais une occasion de boucher une fuite. Quand on (Flock) en trouve, on soumet un patch à leur bugzilla et généralement ça finit dans trunk assez rapidement. Le problème, c'est qu'on ne peut corriger que ce qu'on trouve. Combien y a-t-il de fuites de mémoire dans Firefox ? Y en a-t-il plus que dans les autres logiciels ? Personne ne sait vraiment, puisque dès lors qu'une fuite est connue elle ne reste pas longtemps. Certains ont tendance à confondre "haute utilisation mémoire" et "fuites de mémoire", c'est par exemple ce qui s'est passé quand Mozilla a introduit le bfCache.

Mais alors... Ce logiciel espagnol?

Ce logiciel n'agit ni sur la mémoire utilisé légitimement, ni sur les fuites de mémoire. Il n'agit pas sur le comportement de Firefox mais sur le comportement de Windows !

Tout le code tourne autour d'une fonction Windows: EmptyWorkingSet. Cette fonction déplace les données du programme depuis la mémoire centrale vers le swap disque. C'est une fonction généralement utilisée quand un programme est réduit dans la barre de notification : l'utilisateur n'utilise plus le programme activement, donc le programme peut faire dodo et mettre ses données sur le disque au lieu de la mémoire centrale.

Ça ne libère pas la mémoire non utilisée. Windows est suffisamment intelligent pour savoir que la mémoire non utilisée, eh ben faut la libérer.

Résultat, si on fait ça sur un logiciel au milieu de l'utilisation, ça va être catastrophique pour les performances puisque le logiciel va devoir charger ses données depuis le disque dur (lent) au lieu de la mémoire centrale (rapide) !

En bref, je vous conseille de faire confiance à Windows pour la gestion de la mémoire, plutôt que d'utiliser ce logiciel qui le bombarde de commandes "met ça en swap"... À moins que vous n'aimiez la musique de votre disque dur qui tourne.


PS: en réponse à la deuxième question de citoyenlambda, la plupart des extensions Firefox marchent dans Flock. Par contre, celles qui posent des problèmes sont souvent les extensions liées aux bookmarks, à causes des grosses modifications qu'on a fait au système de bookmark de Firefox. Donc à essayer... Mais c'est pas sûr que ça marche.

3 commentaires:

glandium a dit…

Il y a un autre problème de mémoire avec Firefox, qui n'est ni dû aux fuites, ni à ses divers caches, et qui est assez dramatique, en fait: la fragmentation. http://blog.pavlov.net/2007/11/10/memory-fragmentation/
Et puis, sous X, la consommation de ressources pixmap sur le serveur X, et à une moindre mesure avec les ressources GDI sous windows. https://bugzilla.mozilla.org/show_bug.cgi?id=296818

citoyenlambda a dit…

Merci pour ce post.
pour info je ne confonds pas utilisation intensive voire même excessive de mémoire et fuite, j'ai également fait cette rectification dans un commentaire sur le post techcrunch (j'ai developpé 14 ans du soft embarqué dans des switchs).

Cela dit je pense que l'idée de swapper sur le disque n'est pas idiote vu l'utilisation d'un grand nombre d'onglets que permet Firefox.

Bien évidemment on ne peut regarder tous les onglets en même temps.
Je suis un des "affreux" mais j'ai 8 fenetres Firefox avec jusqu'à 60 onglets par fenetres.

ça ne me choquerait pas que quand je rappelle une fenetre pas regardée depuis longtemmps, elle n'apparaisse pas tout de suite.

de toute façon quand avec un grand nombre d'onglet Ffox ne repond plus tres vite et je n'ai trouvé que killer le process avec le gestionnaire de tâche et redémarrer ffox 2.0 avec restauration de la session pour m'en sortir.

je pense que le cache pour voir rapidement la page précédente devrait avoir un "aging" par exemple 20 minutes (voir regable dans l'onglet avancé).

reste que la consommation de mémoire de ffox est vraiment sa plus grande plaie et à mon avis la raison la plus importante pour en changer.

N.B j'ai visionné la demo flock sur fr.intruders.tv et j'ai été impressionné par la facilité avec laquelle on peut bloguer quelque chose avec flock bravo pour ça.
En ce qui me concerne avec mon blog hebergé par lemonde.fr sans login wordpress je pense que je ne pourrai pas l'utiliser, en attendant que je le fasse heberger ailleurs.
Bon courage en californie
C.L

Erwan a dit…

glandium: merci pour la précision! En effet il y a beaucoup de choses qui pourraient être perfectionnées (et qui l'ont été dans Gecko 1.9) pour améliorer l'empreinte mémoire.

citoyenlambda: en fait, Firefox et Flock vont se comporter comme ça naturellement. Tant que ta mémoire centrale n'est pas pleine, rien ne part en swap. Et tant mieux, parce qu'il n'y a aucune raison de mettre quoi que ce soit en cache s'il reste de la place en mémoire centrale. Donc si tu as beaucoup de mémoire vive (c'est plus très cher maintenant) ce n'est pas trop un souci pour toi.

Quand la mémoire centrale est pleine, le système (Windows dans ton cas) va décider de mettre certaines pages en swap. Chaque OS a un algorithme pour évaluer quelle page a le moins de chances d'être utilisée prochainement. Donc si tu as une fenêtre minimisée pendant pas mal de temps, il y a de bonnes chances pour que ses données partent en swap assez vite.

Si tu as Thunderbird qui dort dans un coin pendant que tu browse le web activement, ce sont les données de Thunderbird qui partiront en swap avant celles de ton navigateur. Normal: tu as besoin des données de ton navigateur, vu que tu l'utilises activement.

Le fait que Firefox "freeze" si tu as trop de fenêtres et d'onglets ouverts, a mon avis est plutôt du à un problème qui je qualifierai plus sérieux que l'utilisation mémoire : il n'y a qu'une seule thread, et une page assez lourde à charger peut bloquer l'interface complètement.

Il y a une API pour les threads dans Firefox, mais la plupart des ressources ne sont pas thread-safe donc c'est difficile à vraiment en tirer parti.