From 39f2114f9797eb51994966c6bb8ff1814c9a4da8 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 12:36:08 +0100 Subject: unslug fr: move --- files/fr/tools/memory/aggregate_view/index.html | 149 ++++++++++++++++++++ files/fr/tools/memory/basic_operations/index.html | 64 +++++++++ .../tools/memory/dom_allocation_example/index.html | 54 +++++++ files/fr/tools/memory/dominators/index.html | 62 ++++++++ files/fr/tools/memory/dominators_view/index.html | 156 +++++++++++++++++++++ files/fr/tools/memory/index.html | 68 +++++++++ files/fr/tools/memory/monster_example/index.html | 81 +++++++++++ files/fr/tools/memory/tree_map_view/index.html | 45 ++++++ 8 files changed, 679 insertions(+) create mode 100644 files/fr/tools/memory/aggregate_view/index.html create mode 100644 files/fr/tools/memory/basic_operations/index.html create mode 100644 files/fr/tools/memory/dom_allocation_example/index.html create mode 100644 files/fr/tools/memory/dominators/index.html create mode 100644 files/fr/tools/memory/dominators_view/index.html create mode 100644 files/fr/tools/memory/index.html create mode 100644 files/fr/tools/memory/monster_example/index.html create mode 100644 files/fr/tools/memory/tree_map_view/index.html (limited to 'files/fr/tools/memory') diff --git a/files/fr/tools/memory/aggregate_view/index.html b/files/fr/tools/memory/aggregate_view/index.html new file mode 100644 index 0000000000..add2eb1979 --- /dev/null +++ b/files/fr/tools/memory/aggregate_view/index.html @@ -0,0 +1,149 @@ +--- +title: Vue "Agrégats" +slug: Outils/Memory/Aggregate_view +translation_of: Tools/Memory/Aggregate_view +--- +
{{ToolsSidebar}}

Avant Firefox 48 il s'agissait de la vue par défaut. Après Firefox 48, la vue "Carte proportionnelle" est la vue par défaut. Pour afficher la vue "Agrégats", il suffit de le sélectionner dans la liste déroulante "vue" :

+ +

+ +

Cette vue ressemble à ceci :

+ +

+ +

Cela représente un tableau qui affiche une liste triée du contenu de la heap. Il y a trois façons différentes de visualiser la heap :

+ + + +

Pour passer de l'une à l'autre, il suffit d'utiliser la liste déroulante "Trier par" en haut du panneau.

+ +

En haut à droite, se trouve le champ "Filtrer". Il permet de filtrer le contenu affiché, afin par exemple de pouvoir rapidement voir combien d'objets d'une classe ont été alloués.

+ +

Type

+ +

Il s'agit du tri par défaut qui ressemble à ceci :

+ +

+ +

Cette option regroupe la heap par grandes catégories :

+ + + +

Chaque type occupe une ligne du tableau. Les lignes sont triées par ordre décroissant d'utilisation mémoire. Par exemple dans la capture d'écran ci-dessus, il est possible de voir que les Objects JavaScriptoccupent la plus grande partie de la mémoire. Suivis par les stings.

+ + + +
+
Les captures d'écran sur cette page montrent des instantanés capturés grâce à l'exemple "monster"
+
+ +

Par exemple, dans la capture d'écran ci-dessus, on peut voir que :

+ + + +

A coté du nom de chaque type, on trouve une icône en forme de trois étoiles en triangle :

+ +

+ +

Cliquer sur cette icône affichera toutes les instances de ce type. Par exemple cliquer sur l'icône de Array affichera les quatre instances :

+ +

+ +

Pour chaque instance, on peut voir taille retenue et la taille de l'objet de cette instance. Dans ce cas, il est possible de voir que les trois premiers tableaux ont une taille importante (5% du total de la heap) et une traille retenue encore plus importante (26% du total).

+ +

Dans la partie droite, on retrouve un panneau qui affiche simplement une phrase. Sélectionner un noeud affichera chemins de rétention :

+ +

+ +

{{EmbedYouTube("uLjzrvx_VCg")}}

+ +

Call Stack

+ +

La pile d'allocation (call stack) affiche exactement ou dans le code sont faites des allocations sur la heap.

+ +

Cette option étant gourmande en terme de performances, elle n'est pas activée par défaut. Pour l'activer, il faut cocher la case "Enregistrer les piles d'allocations avant d'allouer la mémoire dans la capture.

+ +

Une liste de toutes les fonctions qui ont alloué des objets s'affichera alors. Cette liste est triée par la taille des allocations :

+ +


+ La structure de ce tri ressemble fortement à celle de l'Arbre d'appel, à ceci près qu'il montre les allocations plutôt que des échantillons de processus. Par exemple, la première ligne ligne affiche que :

+ + + +

Il est possible d'utiliser l'icône en forme de triangle pour avoir plus de précisions et trouver l'endroit exact d'où l'allocation à été faite.

+ +

Il est plus simple d'expliquer ce comportement avec un exemple. Cette page contient contient simplement un script qui génère un grand nombre de nœuds DOM (200 objets HTMLDivElement et 4000 objets HTMLSpanElement) :

+ +

Réalisons maintenant une allocation trace. Pour cela, il faut :

+ +
    +
  1. Ouvrir l'outil Mémoire
    2. +
  2. Cocher "Enregistrer les piles d'allocations"
    3. +
  3. Charger la page https://mdn.github.io/performance-scenarios/dom-allocs/alloc.html
    4. +
  4. Prendre une capture
    5. +
  5. Choisir la vue "Agrégats"
    6. +
  6. Choisir le regroupement par "Call Stack"
    7. +
+ +

{{EmbedYouTube("aZ5Rq9lXD80")}}

+ +

Quelque chose comme ceci devrait apparaitre :

+ +

+ +

Cela révèle que 93% sont allouées par des fonctions appelées depuis "alloc.js", à la ligne 35 (le premier appel à createToolbars()).

+ +

Afin de savoir exactement d'où est allouée la mémoire, il est possible de développer la ligne :

+ +

+ +

C'est dans ce cas que les colonnes "Octets" et "Somme" sont utiles. Elles révèlent en effet la taille et le nombre des allocations faites à ce point précis.

+ +

Ainsi dans l'exemple ci-dessus, ile est possible de voir que dans createToolbarButton(), à la ligne 9 de alloc.js, 4002 allocations ont été faites et que cela représente 89% de la heap totale. Il s'agit de l'endroit exact ou les éléments {{HTMLElement("span")}} sont crées.

+ +

Les noms de fichier et leur numéro de ligne sont des liens : cliquer dessus ouvrira la ligne en question dans le Débogueur :

+ +

{{EmbedYouTube("zlnJcr1IFyY")}}

+ +

Inverted Call Stack

+ +

La vue par défaut est une vue "top-down" : elle affiche les allocations qui arrivent à un point ou en des points plus loin dans l'arbre. C'est pratique pour avoir une vue d'ensemble des endroits ou le programme consomme beaucoup de mémoire. Cependant cette vue implique de devoir parcourir un long chemin pour trouver l'emplacement exact d'où les allocations sont faites.

+ +

L'option "Inverser l'arbre" aide à résoudre ce problème. Cela donne en effet une vue "bottom-up" du programme, affichant les endroits exacts d'où les allocations proviennent, ordonnés par taille d'allocation. L'icône en forme de triangle fait alors un retour au premier niveau de l'arbre.

+ +

Voici à quoi ressemble l'arbre après avoir coché l'option "Inverser l'arbre" :

+ +

+ +

Maintenant, la première ligne affiche directement l'appel createToolbarButton() qui correspond à l'allocation de 89% de la heap de la page.

+ +

(no stack available)

+ +

Dans l'exemple ci-dessus, il y a une ligne nommée "(no stack available)" qui correspond à 7% de la heap. La présence de cette ligne s'explique par le fait que toute l'utilisation de la heap n'est pas due au script JavaScript.

+ +

Exemples d'usage de la heap non alloué par un script :

+ + + +

Bon nombre de pages web auront une part de "(no stack available)" bien supérieure à 7%.

diff --git a/files/fr/tools/memory/basic_operations/index.html b/files/fr/tools/memory/basic_operations/index.html new file mode 100644 index 0000000000..e132baed90 --- /dev/null +++ b/files/fr/tools/memory/basic_operations/index.html @@ -0,0 +1,64 @@ +--- +title: Opérations de base +slug: Outils/Memory/Basic_operations +translation_of: Tools/Memory/Basic_operations +--- +
{{ToolsSidebar}}

Ouvrir l'outil Mémoire

+ +

L'outil Mémoire n'est pas activé par défaut. Pour l'activer, il faut ouvrir et cocher la case "Mémoire" dans la catégorie "Outils de développement pas défaut" :

+ +

{{EmbedYouTube("qi-0CoCOXwc")}}

+ +

Depuis Firefox 50, l'outil mémoire est activé par défaut.

+ +

Capturer un instantané

+ +

Pour capturer un instantané de la heap il faut cliquer sur le bouton "Capturer un instantané" ou sur l'icône en forme d'appareil photo, en haut à gauche :

+ +

+ +

L'instantané, occupera une large partie du panneau de droite. Sur la gauche, il y aura une liste des instantanés capturée. Ce panneau inclut le timestamp, la taille et les actions supprimer/enregistrer :

+ +

+ +

Supprimer un instantané

+ +

Pour supprimer un instantané, il suffit de cliquer sur l'icône "X" :

+ +

+ +

Sauvegarder et charger des instantanés

+ +

Fermer l'outil, supprimera tous les instantanés non sauvegardés. Pour sauvegarder un instantané, il suffit de cliquer sur "Enregistrer" :

+ +

+ +

Il vous sera ensuite demandé un nom et un emplacement. Le fichier sera alors enregistré avec une extension .fxsnapshot

+ +

Pour charger un instantané depuis un fichier .fxsnapshot, il faut de cliquer sur le bouton en forme de rectangle avec un flèche pointée vers le haut (avant Firefox le bouton avait le texte "Importer") :

+ +

+ +

Il suffit ensuite de sélectionner un instantané précédemment enregistré sur votre disque.

+ +

Comparer des instantanés

+ +

À partir de Firefox 45, il est possible de comparer deux instantanés. Le diff affiche les endroits ou de la mémoire a été allouée, et où de la mémoire a été libéré entre les deux instantanés.

+ +

Pour créer une diff, il faut cliquer sur l'icône en forme de diagramme de Venn en haut à gauche (note: avant Firefox 47, l'icône ressemblait à un "+/-") :

+ +

+ +

Il faut ensuite sélectionner l'instantané qui sert de base de comparaison puis l'instantané à comparer. L'outil affiche alors les différences entre les deux instantanés :

+ +

{{EmbedYouTube("3Ow-mdK6b2M")}}

+ +
+

Lors d'une comparaison, il n'est pas possible d'utiliser la vue "Dominants" ou "Carte proportionnelle"

+
+ +

Enregistrer les piles d'allocations

+ +

L'outil Mémoire permet de savoir exactement où dans le code la mémoire est allouée. Cependant, enregistrer ces informations a un cout en performance. Il faut donc activer manuellement l'enregistrement avant de faire les allocations mémoires. Pour cela, il suffit de cocher la case "Enregistrer les pilles d'allocations" :

+ +

diff --git a/files/fr/tools/memory/dom_allocation_example/index.html b/files/fr/tools/memory/dom_allocation_example/index.html new file mode 100644 index 0000000000..0f3a4b04d6 --- /dev/null +++ b/files/fr/tools/memory/dom_allocation_example/index.html @@ -0,0 +1,54 @@ +--- +title: Exemple d'allocation DOM +slug: Outils/Memory/DOM_allocation_example +translation_of: Tools/Memory/DOM_allocation_example +--- +
{{ToolsSidebar}}

Cet article décrit une page web très simple qui sera utilisée pour illustrer certaines fonctionnalités de l'outil Mémoire.

+ +

Il est possible de visiter le site à l'adresse : https://mdn.github.io/performance-scenarios/dom-allocs/alloc.html.

+ +

Cette page contient simplement un script qui crée un grand nombre de noeuds DOM :

+ +
var toolbarButtonCount = 20;
+var toolbarCount = 200;
+
+function getRandomInt(min, max) {
+    return Math.floor(Math.random() * (max - min + 1)) + min;
+}
+
+function createToolbarButton() {
+  var toolbarButton = document.createElement("span");
+  toolbarButton.classList.add("toolbarbutton");
+  // empêche Spidermonkey de partager les instances
+  toolbarButton[getRandomInt(0,5000)] = "foo";
+  return toolbarButton;
+}
+
+function createToolbar() {
+  var toolbar = document.createElement("div");
+  // empêche Spidermonkey de partager les instances
+  toolbar[getRandomInt(0,5000)] = "foo";
+  for (var i = 0; i < toolbarButtonCount; i++) {
+    var toolbarButton = createToolbarButton();
+    toolbar.appendChild(toolbarButton);
+  }
+  return toolbar;
+}
+
+function createToolbars() {
+  var container = document.getElementById("container");
+  for (var i = 0; i < toolbarCount; i++) {
+    var toolbar = createToolbar();
+    container.appendChild(toolbar);
+  }
+}
+
+createToolbars();
+ +

Voici une représentation en pseudo-code de ce que fait ce code :

+ +
createToolbars()
+    -> createToolbar() // appelé 200 fois. Crée un élément DIV à chaque fois
+       -> createToolbarButton() // appelé 20 fois par toolbar, crée un élément SPAN à chaque fois
+ +

Ainsi, au total ce code crée 200 objets HTMLDivElement, et 4000 objets HTMLSpanElement.

diff --git a/files/fr/tools/memory/dominators/index.html b/files/fr/tools/memory/dominators/index.html new file mode 100644 index 0000000000..30dee2db22 --- /dev/null +++ b/files/fr/tools/memory/dominators/index.html @@ -0,0 +1,62 @@ +--- +title: Dominants +slug: Outils/Memory/Dominators +translation_of: Tools/Memory/Dominators +--- +
{{ToolsSidebar}}
+ +
+

Cet article fournit une introduction aux concepts d'Accessibilité, de taille Objet et de taille Retenue, ainsi que des Dominants, et de comment ses concepts s'appliquent dans des langages à ramasse-miette (garbage-collector) comme le JavaScript.

+ +

Ces concepts sont importants pour l'analyse mémoire, car souvent, un objet peut être en lui même petit, mais contenir des références à des objets beaucoup plus gros et cela empêche le ramasse-miette de collecter ces objets et de libérer de la mémoire.

+ +

Il est possible de voir les dominants d'une page en utilisant la Vue "Dominants"  dans l'outil Mémoire.

+
+ +

Dans un langage comme JavaScript, les programmeurs n'ont généralement pas à se soucier de la gestion de la mémoire. Ils peuvent simplement créer des objets, les utiliser, et lorsque ceux-ci ne sont plus nécessaires, le runtime se charge de faire le nettoyage, et libère la mémoire que les objets utilisaient.

+ +

Accessibilité

+ +

Dans les implémentations modernes de JavaScript, le runtime décide de quand un objet n'est plus nécessaire en se basant sur l'accessibilité. Dans ce système, la heap est représentée par un ou plusieurs graphes. Chaque noeud dans le graphe représente un objet, et chaque connexion entre les noeuds (edge) représente une référence d'un objet à un autre. Le graphe commence au noeud racine, indiqué dans les diagrammes suivant par un "R" :

+ +

+ +

Lors du passage du ramasse-miette, le runtime parcourt le graphe à partir de la racine et marque chaque objet qu'il trouve. Tous les objets qui ne sont pas trouvés dans ce parcours, ne sont pas accessibles et peuvent être désalloués.

+ +

Donc lorsqu'un objet devient inaccessible (par exemple parce qu'il était référencé par une seule variable locale qui sort du scope actuel) alors tout objet qu'il référence devient également inaccessible à son tour (sauf s’il était référencé par d'autres objets qui sont eux toujours accessibles) :

+ +

+ +

A l'inverse, cela veut dire que des objets sont gardés en vie tant qu'un autre objet accessible comporte une référence à cet objet.

+ +

Taille de l'objet et taille retenue

+ +

Tout cela donne naissance à deux façons différentes de considérer la taille d'un objet :

+ + + +

Souvent, les objets auront une taille d'objet faible, mais une bien plus grande taille retenue, à cause de ses références à d'autres objets. La taille retenue est un concept important dans l'analyse de l'utilisation mémoire, car cela répond à la question "si cet objet cesse d'exister, quelle est la taille de mémoire libérée ?".

+ +

Dominants

+ +

Un concept lié à cela est le concept de dominants. Un noeud B "domine" le noeud A si tous les chemins depuis la racine jusqu'à A passent par B :

+ +

+ +

Si un des noeuds dominants du noeud A est libéré, alors le noeud A lui-même devient éligible au ramasse-miette.

+ +

Si le noeud B domine le noeud A mais ne domine aucun des dominants de A, alors B est le dominant immédiat de A :

+ +

+ +

Une subtilité ici est que si un objet A est référencé par deux autres objets B et C, alors aucun de ces deux objets n'est un dominant de A, car il est possible de retirer soit B soit C du graphe et A serait alors toujours référencé par son autre référent. À la place, le dominant immédiat de A est le premier ancêtre commun :
+

+ +

Voir Aussi

+ +

Les dominants dans la théorie des graphes.

+ +

Tracing garbage collection.

diff --git a/files/fr/tools/memory/dominators_view/index.html b/files/fr/tools/memory/dominators_view/index.html new file mode 100644 index 0000000000..bfa472bded --- /dev/null +++ b/files/fr/tools/memory/dominators_view/index.html @@ -0,0 +1,156 @@ +--- +title: Vue "Dominants" +slug: Outils/Memory/Dominators_view +translation_of: Tools/Memory/Dominators_view +--- +
{{ToolsSidebar}}
+

La vue "Dominants" est une des nouveautés de Firefox 46.

+
+ +

À partir de Firefox 46, l'outil Mémoire inclut une nouvelle vue nommée "Dominants". Celle-ci est utile pour comprendre la "Taille retenue" des objets d'un site : il s'agit de la taille des objets eux-mêmes ainsi que la taille des objets qu'ils gardent en vie par référence.

+ +

Si vous n'êtes pas familier avec la "taille de l'objet", la "taille retenue" et les Dominants, il est recommandé de lire l'article sur les concepts des Dominants.

+ +

Interface utilisateur des Dominants

+ +

Pour afficher la vue des Dominants, il faut sélectionner "Dominants" dans le menu déroulant "Afficher" :

+ +

+ +

Cette vue est constituée de deux panneaux:

+ + + +

+ +

Arbre des Dominants

+ +

Ce panneau affiche les objets de la capture qui retiennent le plus de mémoire.

+ +

Dans la partie principale de l'UI, la première ligne est nommée "Racines GC". En dessous de cette ligne, il y a une ligne pour :

+ + + +

Pour chacune de ces lignes, seront affichés :

+ + + +

Les lignes sont classées par la taille de mémoire retenue. Par exemple :

+ +

+ +

Dans cette capture d'écran, il est possible de voir qu'il y a cinq linges en dessus de "GC roots". Les deux premiers objets sont "Call" et "Window", et retiennent respectivement 21% et 8% de la mémoire totale de la capture. Il est également possible de voir qu'ils ont une taille (shallow) réduite, donc quasiment toute la mémoire retenue vient d'objets qu'ils dominent.

+ +

Juste en dessous de chaque racine GC, tout les noeuds pour lequel cette racine est le dominant immédiat sont affichés et triés par taille retenue.

+ +

Par exemple, cliquer sur le premier objet "Window" affichera ceci :

+ +

+ +

Il est possible de voir que "Window" domine un objet "CSS2Properties", dont la taille retenue est de 2ù de la capture. Encore une fois, la taille de l'objet est faible, quasiment toute sa taille retenue est due aux objets dominés. En cliquant sur l'icone en fore de triangle à coté de la fonction, il est possible de voir ces noeuds.

+ +

Il est ainsi possible de se faire rapidement une idée de quels objets retiennent le plus de mémoire dans la capture.

+ +

Il est possible d'utiliser Alt + clic pour étendre le graph entier d'un noeud.

+ +

Pile d'allocations

+ +

Dans la barre d'outils, il y a une liste déroulante : "Nommer selon" :

+ +

+ +

Par défaut, l'option sélectionnée est "Type". Il est possible de choisir "Call Stack" à la place pour savoir exactement d'ou dans le code les objets sont alloués.

+ +
+

Cette option est appelée "Allocation Stack" dans Firefox 46.

+
+ +

Pour l'activer, il faut cocher la case "Enregistrer les piles d'allocations" avant de lancer le coder qui alloue les objets. Il faut ensuite prendre une capture, puis sélectionner "Call Stack" dans le menu déroulant "Nommer selon".

+ +

Maintenant, le nom du noeud contient le nom de la fonction qui l'a alloué, ainsi que le fichier, la ligne et la position exacte d'ou dans la fonction l'allocation a été faite. Cliquer sur le nom du fichier ouvrira cette position dans le Débogueur.

+ +

{{EmbedYouTube("qTF5wCSD124")}}

+ +
+

Parfois, une ligne nommée "(no stack available)" est présente. Les piles d'allocations ne sont actuellement enregistrées que pour les objets, pas pour les tableaux, les strings ou les structures internes.

+
+ +

Chemins de rétention

+ +
Ce panneau est une des nouveautés de Firefox 47.
+ +

Ce panneau affiche, pour un noeud sélectionné les 5 plus courts chemins depuis ce noeud jusqu'a une racine GC. Cela permet de voir tous les noeuds qui empêchent ce noeud d'être détruit par le garbage collector (ramasse-miette en bon français). Si un objet est soupçonné de cause une fuite mémoire, ce panneau affichera les objets qui réfrènent l'objet soupçonné.

+ +

Pour voir le chemin de rétention, il suffit de sélectionner un noeud dans le panneau de l'arbre des Dominants :

+ +

+ +

Ici, un objet a été sélectionné et l'on peut voir un unique chemin jusqu'a la racine GC.

+ +

La racine GC Window contient une référence à un objet HTMLDivElement. Cet objet contient lui une référence à un Object, et ainsi de suite. Il est possible de retracer le chemin juste en regardant le panneau de l'arbre des Dominants. Si une seule de ces références venait à être supprimée, les objets en dessous seraient détruits par le garbage collector.

+ +

Chaque connexion dans le graph est annoté avec le nom de la variable qui référence l'objet.

+ +

Parfois, il y a plus d'un seul chemin de rétention :

+ +

+ +

Ici, il y a deux chemins depuis le noeud DocumentPrototype vers la racine GC. Si seulement l'un des des deux venait à être supprimé, le noeud ne serait pas détruit par le garbage collector, puisqu'il serait toujours retenu par l'autre chemin.

+ +

Exemple

+ +

Pour tester l'outil, il est plus simple d'utiliser un exemple

+ +


+ Nous utiliserons l'exemple d'allocation de monstres. Cet exemple crée trois tableaux chacun contenant 5000 monstres, chaque monstre possède un nom généré aléatoirement.
+  

+ +

Prendre une capture

+ +

Pour voir à quoi cela ressemble avec la vue "Dominants", il faut :

+ + + +

{{EmbedYouTube("HiWnfMoMs2c")}}

+ +

Analyse de l'arbre des dominants

+ +

Les trois tableaux seront les trois premières racines GC, chacun retenant à peu près 23% de la mémoire totale de la capture :

+ +

+ +

Étendre un tableau affichera les objets (monstres) qu'il contient. Chaque monstre à une taille réduite de 160 octets. Cette taille inclut les variables int "eye" et "tentacle-count". Chaque monstre à une taille retenue plus grande, car ils retiennent la string utilisée pour stocker le nom du monstre :

+ +

+ +

Tout cela se rapproche précisément du graph mémoire attendu. Une chose curieuse cependant, où est passé l'objet qui contient ces trois tableaux ? En regardant le chemin de rétention pour un des tableaux, il est possible de le voir :

+ +

+ +

Ici, il est possible de voir l'objet retenant le tableau; et même qu'il s'agit du tableau de monstres friendly. Dans la capture d'écran ci-dessus, ce n'est pas visible, cependant ce tableau est aussi enraciné directement à la racine GC. Donc si l'objet arrête de référencer le tableau, celui-ci ne serait toujours pas éligible au garbage collector.

+ +

Cela veut dire que l'objet ne domine pas le tableau et donc n'est pas affiché dans l'arbre des Dominants. À voir également,  l'article sur le concept des Dominants.

+ +

Utiliser la vue Call Stack

+ +

Enfin, il est possible de passer à la vue "Call Stack", afin de voir quels objets sont alloués et de se rendre à ce point dans le Débogueur :

+ +

{{EmbedYouTube("qTF5wCSD124")}}

diff --git a/files/fr/tools/memory/index.html b/files/fr/tools/memory/index.html new file mode 100644 index 0000000000..017e5b69c5 --- /dev/null +++ b/files/fr/tools/memory/index.html @@ -0,0 +1,68 @@ +--- +title: Mémoire +slug: Outils/Memory +tags: + - DevTools + - Firefox + - Mozilla + - Tools + - outils de développement +translation_of: Tools/Memory +--- +
{{ToolsSidebar}}

L'outil Mémoire permet de prendre une capture de l'état actuel de la heap de la mémoire. Il fournit plusieurs manières de visualiser la heap. Cela permet de voir la taille mémoire que prennent les objets et les endroits exacts du code d'où la mémoire est allouée.

+ +

{{EmbedYouTube("DJLoq5E5ww0")}}

+ +
+

La base

+ +
+ +
+ +
+

Analyser les captures

+ +
+

La vue "carte proportionnelle" est une nouveauté de Firefox 48, la vue "Dominants" est une nouveauté de Firefox 46.

+
+ +

Une fois qu'une capture est prise, il y a deux vues principales que l'outil fournit :

+ + + +

Si l'option "Enregistrer les piles d'allocations" est cochée, les deux vues affichent d'où exactement dans le code les allocations sont originaires.

+ +

Enfin, il est possible de comparer deux captures, et d'analyser le résultat de la différence.

+ +
+

Concepts

+ +
+ +
+ +
+

Pages d'exemples

+ +

Exemples utilisés dans la documentation de l'outil Mémoire :

+ +
+ +
diff --git a/files/fr/tools/memory/monster_example/index.html b/files/fr/tools/memory/monster_example/index.html new file mode 100644 index 0000000000..48357b8d8b --- /dev/null +++ b/files/fr/tools/memory/monster_example/index.html @@ -0,0 +1,81 @@ +--- +title: Exemple d'allocation de monstres +slug: Outils/Memory/Monster_example +translation_of: Tools/Memory/Monster_example +--- +
{{ToolsSidebar}}

Cet article décrit une page web très simple que nous utilisons pour illustrer certaines fonctionnalités de l'outil Mémoire.

+ +

Il est possible de l'essayer sur le site : https://mdn.github.io/performance-scenarios/js-allocs/alloc.html. Voici le code :

+ +
var MONSTER_COUNT = 5000;
+var MIN_NAME_LENGTH = 2;
+var MAX_NAME_LENGTH = 48;
+
+function Monster() {
+
+  function randomInt(min, max) {
+      return Math.floor(Math.random() * (max - min + 1)) + min;
+    }
+
+  function randomName() {
+    var chars = "abcdefghijklmnopqrstuvwxyz";
+    var nameLength = randomInt(MIN_NAME_LENGTH, MAX_NAME_LENGTH);
+    var name = "";
+    for (var j = 0; j &lt; nameLength; j++) {
+      name += chars[randomInt(0, chars.length-1)];
+    }
+    return name;
+  }
+
+  this.name = randomName();
+  this.eyeCount = randomInt(0, 25);
+  this.tentacleCount = randomInt(0, 250);
+}
+
+function makeMonsters() {
+  var monsters = {
+    "friendly": [],
+    "fierce": [],
+    "undecided": []
+  };
+
+  for (var i = 0; i &lt; MONSTER_COUNT; i++) {
+    monsters.friendly.push(new Monster());
+  }
+
+  for (var i = 0; i &lt; MONSTER_COUNT; i++) {
+    monsters.fierce.push(new Monster());
+  }
+
+  for (var i = 0; i &lt; MONSTER_COUNT; i++) {
+    monsters.undecided.push(new Monster());
+  }
+
+  console.log(monsters);
+}
+
+var makeMonstersButton = document.getElementById("make-monsters");
+makeMonstersButton.addEventListener("click", makeMonsters);
+ +

Cette page contient un bouton : Lorsque celui-ci est activé, le code crée des monstres plus précisément :

+ + + +

Ainsi, la structure de la mémoire allouée sur la heap JavaScript est un objet contenant trois tableaux contenant chacun 5000 objets (les monstres) chaque objet contient une string et deux int :

+ +

diff --git a/files/fr/tools/memory/tree_map_view/index.html b/files/fr/tools/memory/tree_map_view/index.html new file mode 100644 index 0000000000..a009e59a7a --- /dev/null +++ b/files/fr/tools/memory/tree_map_view/index.html @@ -0,0 +1,45 @@ +--- +title: Vue carte proportionnelle +slug: Outils/Memory/Tree_map_view +translation_of: Tools/Memory/Tree_map_view +--- +
{{ToolsSidebar}}
+

Cette vue est une des nouveautés de Firefox 48.

+
+ +

La vue carte proportionnelle fournit une représentation visuelle d'une capture instantané de la mémoire. Cela aide à avoir rapidement une idée de quels objets occupent le plus de mémoire.

+ +

Une carte affiche :  "Une représentation de données hiérarchiques dans un espace limité" sous la forme de rectangles imbriqués. La taille de ces rectangles correspond à un aspect quantitatif des données (plus c'est gros, plus le rectangle l'est).

+ +

Pour les cartes affichées dans l'outil Mémoire, la heap (le tas) est divisé en quatre grandes catégories :

+ + + +

Chaque catégorie, est représentée dans un rectangle, et la taille de ce rectangle correspond à la portion de la heap occupée par les éléments de cette catégorie. Cela signifie qu'il est facile d'avoir rapidement une idée de ce qui prend le plus de place mémoire.

+ +

A l’intérieur des grandes catégories :

+ + + +

Voici quelques captures d'exemple, tel qu'elles apparaissent dans la vue carte proportionnelle :

+ +

+ +

Cette carte provient de l'exemple d'allocation DOM, qui crée simplement un grand nombre de nœuds DOM. (200 objets HTMLDivElement et 4000 objets HTMLSpanElement). Il est possible de voir que quasiment tout l'espace occupé dans la heap l'est par les objets HTMLSpanElement crées.

+ +

+ +

Cette carte vient de l'exemple allocation de monstres, qui représente trois tableaux contenant chacun 5000 monstres. Chaque monstre possède un nom aléatoire. Il est possible de voir que la heap est occupée principalement par les strings utilisés pour le nom des monstres, ainsi que par les objets utilisé pour contenir les autres attributs des monstres.

+ +

+ +

Cette carte provient de http://www.bbc.com/, et est probablement plus représentative de la vie réelle que les exemples. Il est possible de voir qu'une partie beaucoup plus importante de la heap est occupée par les scripts qui sont chargés depuis un grand nombre d'origines.

-- cgit v1.2.3-54-g00ecf