Google sort Leak Finder
Un outil JavaScript open source pour aider les développeurs Web à trouver les fuites de mémoire des applications
Le 2012-08-09 13:51:35, par Hinault Romaric, Responsable .NET
La consommation des ressources mémoires par une application a un impact non négligeable sur l’expérience utilisateur. Les développeurs sont très souvent confrontés à des problèmes de fuites de mémoire dans leurs applications, entrainant une utilisation excessive des ressources.
Les développeurs JavaScript qui font face à ce type de problème peuvent pousser un « ouf » de soulagement. Google vient de publier sous une licence open source l’outil JavaScript Leak Finder, qui permettra à ceux-ci de trouver facilement les fuites de mémoire dans leur programme.
Pour un langage garbage-collected comme JavaScript, les développeurs n’ont pas très souvent à se soucier des fuites de mémoire traditionnelles qui sont directement traitées par le ramasse-miette.
Cependant, les applications peuvent par inadvertance conserver des références aux objets, entrainant ainsi des fuites de mémoire. Par exemple, les références peuvent être des pointeurs vers des objets stockés dans une structure de données d’une bibliothèque JavaScript au lieu du code de l’application. Si un objet est involontairement retenu, tous les objets vers lesquels il pointe sont maintenus. Ce qui conduira à une consommation superflue de mémoire.
Leak Finder peut détecter ces objets qui n’ont pas été libérés, et générer des informations (trace de la pile lorsque l’objet a été créé par exemple) à leur sujet. Il produit un rapport qui peut être utilisé comme une partie des tests automatisés.
Leak Finder peut-être utilisé avec la bibliothèque JavaScript de Google Closure, mais peut également être adapté pour d’autres bibliothèques JavaScript.
Source : Blog open source Google
Et vous ?
Les développeurs JavaScript qui font face à ce type de problème peuvent pousser un « ouf » de soulagement. Google vient de publier sous une licence open source l’outil JavaScript Leak Finder, qui permettra à ceux-ci de trouver facilement les fuites de mémoire dans leur programme.
Pour un langage garbage-collected comme JavaScript, les développeurs n’ont pas très souvent à se soucier des fuites de mémoire traditionnelles qui sont directement traitées par le ramasse-miette.
Cependant, les applications peuvent par inadvertance conserver des références aux objets, entrainant ainsi des fuites de mémoire. Par exemple, les références peuvent être des pointeurs vers des objets stockés dans une structure de données d’une bibliothèque JavaScript au lieu du code de l’application. Si un objet est involontairement retenu, tous les objets vers lesquels il pointe sont maintenus. Ce qui conduira à une consommation superflue de mémoire.
Leak Finder peut détecter ces objets qui n’ont pas été libérés, et générer des informations (trace de la pile lorsque l’objet a été créé par exemple) à leur sujet. Il produit un rapport qui peut être utilisé comme une partie des tests automatisés.
Leak Finder peut-être utilisé avec la bibliothèque JavaScript de Google Closure, mais peut également être adapté pour d’autres bibliothèques JavaScript.
Source : Blog open source Google
Et vous ?
transgohan
Expert éminent
Cependant, les applications peuvent par inadvertance conserver des références aux objets, entrainant ainsi des fuites de mémoire. Par exemple, les références peuvent être des pointeurs vers des objets stockés dans une structure de données d’une bibliothèque JavaScript au lieu du code de l’application. Si un objet est involontairement retenu, tous les objets vers lesquels il pointe sont maintenus. Ce qui conduira à une consommation superflue de mémoire.
L'évènement onclose ou similaire serait obligatoirement chargé de ce travail mais du fait de la charge de données je doute que tous les navigateurs apprécient.
Or vu qu'on trouve de plus en plus d'applications JS qui prennent le pas sur le serveur et donc chargent beaucoup de données sur le client...
M'enfin, voilà l'avis d'un développeur qui n'est absolument pas spécialisé dans ce langage, mais qui avec ses maigres connaissances pensent à cela.
le 10/08/2012 à 11:42