From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- files/ja/tools/memory/aggregate_view/index.html | 150 ++++++++++++++++++++ files/ja/tools/memory/basic_operations/index.html | 64 +++++++++ .../memory/comparing_heap_snapshots/index.html | 14 ++ .../tools/memory/dom_allocation_example/index.html | 54 ++++++++ files/ja/tools/memory/dominators/index.html | 61 ++++++++ files/ja/tools/memory/dominators_view/index.html | 154 +++++++++++++++++++++ files/ja/tools/memory/index.html | 65 +++++++++ files/ja/tools/memory/monster_example/index.html | 81 +++++++++++ files/ja/tools/memory/tree_map_view/index.html | 45 ++++++ 9 files changed, 688 insertions(+) create mode 100644 files/ja/tools/memory/aggregate_view/index.html create mode 100644 files/ja/tools/memory/basic_operations/index.html create mode 100644 files/ja/tools/memory/comparing_heap_snapshots/index.html create mode 100644 files/ja/tools/memory/dom_allocation_example/index.html create mode 100644 files/ja/tools/memory/dominators/index.html create mode 100644 files/ja/tools/memory/dominators_view/index.html create mode 100644 files/ja/tools/memory/index.html create mode 100644 files/ja/tools/memory/monster_example/index.html create mode 100644 files/ja/tools/memory/tree_map_view/index.html (limited to 'files/ja/tools/memory') diff --git a/files/ja/tools/memory/aggregate_view/index.html b/files/ja/tools/memory/aggregate_view/index.html new file mode 100644 index 0000000000..8517a99791 --- /dev/null +++ b/files/ja/tools/memory/aggregate_view/index.html @@ -0,0 +1,150 @@ +--- +title: 総計ビュー +slug: Tools/Memory/Aggregate_view +translation_of: Tools/Memory/Aggregate_view +--- +
{{ToolsSidebar}}

Firefox 48 より前のバージョンでは、このビューがヒープスナップショットの既定のビューでした。Firefox 48 より既定のビューが ツリーマップビュー になりましたが、"表示:" のドロップダウンリストで総計ビューに切り替えできます:

+ +

+ +

総計ビューは、以下のようなものです:

+ +

+ +

これは、ヒープの内容の内訳を表形式で表示します。データをグループ化する方法は、主に 3 つあります:

+ + + +

これらは、パネルの上部にある "グループ化" ドロップダウンリストで変更できます:

+ +

また、ペインの右上に "フィルター" と表示されているボックスがあります。表示するスナップショットの内容をフィルタリングできますので、例えば特定のクラスのオブジェクトがいくつアロケートされているかをすばやく確認できます。

+ +

Type

+ +

これはデフォルトのビューであり、以下のようなものです:

+ +

+ +

このビューは、ヒープの内容を以下のタイプに分類します:

+ + + +

それぞれのタイプを表の行に表示して、これらの行は、そのタイプのオブジェクトが占めるメモリーの量の順に並べます。例えば前出のスクリーンショットでは、JavaScript の Object がもっとも多くのメモリ、また strings が 2 番目に多くのメモリーを占めていることがわかります。

+ + + +
+
このセクションのスクリーンショットは、monster example page のスナップショットから取得しました。
+
+ +

例えば前出のスクリーンショットでは、以下のことがわかります:

+ + + +

タイプ名の隣に、3 つの星印が三角形のように配置されているアイコンがあります:

+ +

+ +

これをクリックすると、そのタイプのすべてのインスタンスを確認できます。例えば Array では、スナップショット内に Array オブジェクトが 4 個あると表示しています。3 つの星印をクリックすると、4 個の Array インスタンスを表示します:

+ +

+ +

それぞれのインスタンスで、保持サイズとシャローサイズ を確認できます。このスクリーンショットでは、上から 3 個の配列のシャローサイズがかなり多く (ヒープ全体の 5%)、またより多くの保持サイズ (全体の 26%) を占めていることがわかります。

+ +

右側には、"保持パスを表示するノードを選択してください" と表示されているペインがあります。項目を選択すると、その項目の 保持パスパネル を表示します:

+ +

+ +

{{EmbedYouTube("uLjzrvx_VCg")}}

+ +

Call Stack

+ +

Call Stack では、コードのどこでメモリーの割り当てを行っているかを表示します。

+ +

メモリー割り当てのトレースは負荷が高いため、スナップショットでメモリー割り当てが行われる前に "割り当てスタックを記録" にチェックを入れて、明示的に有効化しなければなりません:

+ +

オブジェクトの割り当てを行ったすべての関数を、割り当てたサイズ順に並べて表示します:

+ +


+
+ このビューの構造は コールツリー の構造とよく似ていますが、プロセッサーのサンプルではなく割り当てのみ表示します。例えば、最初の項目では以下のことがわかります:

+ + + +

展開用の三角印を使用してコールツリーの細分化が可能であり、コード内で割り当てを行った箇所を正確に知ることができます。

+ +

シンプルな例を使用して、簡単に説明します。ここでは DOM allocation example を使用します。このページは大量の DOM ノード (200 個の HTMLDivElement オブジェクトと 4000 個の HTMLSpanElement オブジェクト) を生成するスクリプトを実行します。

+ +

メモリ割り当てをトレースしてみましょう:

+ +
    +
  1. メモリツールを開きます。
    2. +
  2. "割り当てスタックを記録" にチェックを入れます。
    3. +
  3. https://mdn.github.io/performance-scenarios/dom-allocs/alloc.html を開きます。
    4. +
  4. スナップショットを採取します。
    5. +
  5. "表示/総計" を選択します。
    6. +
  6. "グループ化/Call Stack" を選択します。
    7. +
+ +

{{EmbedYouTube("DyLulu9eoKY")}}

+ +

ビューは以下のようになるでしょう:

+ +

+ +

これは、ヒープスナップショット全体の 93% を "alloc.js" の 35 行目で呼び出した関数 (始めに呼び出す createToolbars()) が割り当てていることを示しています。

+ +

展開用の三角印を使用してツリーを展開すると、どこでメモリーの割り当てを行っているかを正確に知ることができます:

+ +

+ +

ここでは "バイト" 列と "個数" 列が役に立ちます。これは割り当てたメモリーのサイズと、割り当て数を示します。

+ +

前出の例では alloc.js の 9 行目・23 桁目 にある createToolbarButton() で 4002 個のメモリー領域を割り当てており、それはヒープ全体の 84% を占めています。つまり正確な場所は、{{HTMLElement("span")}} 要素を生成している場所です。

+ +

ファイル名と行番号はリンクになっています。クリックすると、デバッガーでその行を表示します:

+ +

{{EmbedYouTube("zlnJcr1IFyY")}}

+ +

Inverted Call Stack

+ +

Call Stack ビューは、トップダウン型です。これは、メモリーの割り当てが発生した箇所をコールツリーの深部に表示します。よって、プログラムのどこでメモリーを大量に消費しているかの概要を知るのに適しています。しかし、このビューでは割り当てが発生した正確な場所を知るために、ツリーを長くたどらなければなりません。

+ +

"Inverted Call Stack" ビューが役に立ちます。これはメモリー割り当てが発生した正確な場所を、割り当てサイズの順に並べたボトムアップ型のビューです。ツリーを展開すると、トップレベルに向かってコールツリーをたどります。

+ +

上記の例で "Inverted Call Stack" を選択すると、どのようになるかを見てみましょう:

+ +

+ +

リストの最初に、ページでヒープの 89% を占めている createToolbarButton() があります。

+ +

(有効なスタックはありません)

+ +

前出の例で、ヒープの 7% が "(有効なスタックはありません)" であることに気づいているでしょう。これは、ヒープのすべてを JavaScript で使用しているわけではないためです。

+ +

例えば、以下のようなものがあります:

+ + + +

実在するページの多くは、"(有効なスタックはありません)" の割合が 7% を超えます。

diff --git a/files/ja/tools/memory/basic_operations/index.html b/files/ja/tools/memory/basic_operations/index.html new file mode 100644 index 0000000000..0684ae5d1b --- /dev/null +++ b/files/ja/tools/memory/basic_operations/index.html @@ -0,0 +1,64 @@ +--- +title: 基本操作 +slug: Tools/Memory/Basic_operations +translation_of: Tools/Memory/Basic_operations +--- +
{{ToolsSidebar}}

メモリーツールを開く

+ +

Firefox 50 より前のバージョンでは、メモリーツールをデフォルトで無効化しています。有効化するには開発ツールのオプションを開き、"標準の Firefox 開発ツール" 配下の "メモリー" にチェックを入れてください:

+ +

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

+ +

Firefox 50 より、メモリーツールをデフォルトで有効化しています。

+ +

ヒープのスナップショットを採取する

+ +

" スナップショットを採取 " ボタンまたはツールの左側にあるカメラのアイコンをクリックすると、ヒープのスナップショットを採取します:

+ +

+ +

スナップショットは、右側にある大きなペインを占めています。左側には、新しいスナップショットの項目をタイムスタンプ、サイズ、保存や削除のためのコントロールとともに表示します:

+ +

+ +

スナップショットを削除する

+ +

" X "  印のアイコンをクリックすると、スナップショットを削除します:

+ +

+ +

スナップショットの保存と読み込み

+ +

メモリーツールを閉じると、保存していないスナップショットはすべて破棄されます。" 保存 " をクリックすると、スナップショットを保存します:

+ +

+ +

保存先やファイル名を求められます。そしてファイルは、.fxsnapshot という拡張子をつけて保存されます。

+ +

既存の .fxsnapshot ファイルからスナップショットを読み込むには、四角形から上向きの矢印が出ているデザインのインポートボタン (Firefox 49 より前のバージョンでは、" Import... " というラベルがついていました) をクリックします:

+ +

+ +

ディスク上のファイルを選択するよう、求められます。

+ +

スナップショットを比較する

+ +

Firefox 45 より、2 つのヒープのスナップショットの差分を確認できます。これは 2 つのスナップショット間で、メモリーのアロケートや空き状態の違いを表示します。

+ +

差分を作成するには、カメラのアイコンの隣にあるベン図のボタンを押下してください (Firefox 47 より前は、" +/- " 印のアイコンでした)。

+ +

+ +

始めにベースラインのスナップショット、続いて比較するスナップショットを選択するよう求められます。ツールが 2 つのスナップショットの差分を表示します:

+ +

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

+ +
+

差分を表示しているとき、ドミネータービューやツリーマップは使用できません。

+
+ +

コールスタックを記録する

+ +

メモリーツールは、コードのどこでメモリの割り当てを行っているかを表示できます。ただしこの情報の記録は実行時の負荷が高いため、スナップショット内でメモリー呼び出しを行った場所を確認したい場合は、メモリー割り当ての前にツールに対してメモリー呼び出しを記録するよう要求しなければなりません。記録するには、"コールスタックを記録" (Firefox 49 より前は "割り当てスタックを記録" でした) にチェックを入れます:

+ +

diff --git a/files/ja/tools/memory/comparing_heap_snapshots/index.html b/files/ja/tools/memory/comparing_heap_snapshots/index.html new file mode 100644 index 0000000000..ccd50f7618 --- /dev/null +++ b/files/ja/tools/memory/comparing_heap_snapshots/index.html @@ -0,0 +1,14 @@ +--- +title: ヒープのスナップショットを比較する +slug: Tools/Memory/Comparing_heap_snapshots +translation_of: Tools/Memory/Basic_operations +--- +
{{ToolsSidebar}}
+

これは Firefox 45 の新機能です。

+
+ +

Firefox 45 より、2 つのヒープのスナップショットの差分を確認できます。これは 2 つのスナップショット間で、メモリのアロケートや空き状態の違いを表示します。

+ +

差分を作成するにはカメラのアイコンの隣にある "+/-" ボタンを押下して、基準とするスナップショットを選択します。そして、比較するスナップショットを選択してください。ツールが 2 つのスナップショットの差分を表示します。単体のスナップショットの場合と同じビューを使用して、差分を分析できます。

+ +

{{EmbedYouTube("rbDHVxCzqhU")}}

diff --git a/files/ja/tools/memory/dom_allocation_example/index.html b/files/ja/tools/memory/dom_allocation_example/index.html new file mode 100644 index 0000000000..e8449908ce --- /dev/null +++ b/files/ja/tools/memory/dom_allocation_example/index.html @@ -0,0 +1,54 @@ +--- +title: DOMの割り当て例 +slug: Tools/Memory/DOM_allocation_example +translation_of: Tools/Memory/DOM_allocation_example +--- +
{{ToolsSidebar}}

この記事では、メモリーツールの機能を示すために使用するシンプルなページについて説明します。

+ +

これは https://mdn.github.io/performance-scenarios/dom-allocs/alloc.html で試すことができます。

+ +

このページは、大量の 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");
+  // stop Spidermonkey from sharing instances
+  toolbarButton[getRandomInt(0,5000)] = "foo";
+  return toolbarButton;
+}
+
+function createToolbar() {
+  var toolbar = document.createElement("div");
+  // stop Spidermonkey from sharing 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();
+ +

このコードの動作を簡単に表現すると、以下のようになります:

+ +
createToolbars()
+    -> createToolbar() // 200 回呼び出され、毎回 1 個の DIV 要素を生成します
+       -> createToolbarButton() // Toolbar ごとに 20 回呼び出され、毎回 1 個の SPAN 要素を生成します
+ +

最終的に、200 個の HTMLDivElement オブジェクトと 4,000 個の HTMLSpanElement オブジェクトを生成します。

diff --git a/files/ja/tools/memory/dominators/index.html b/files/ja/tools/memory/dominators/index.html new file mode 100644 index 0000000000..3db9506921 --- /dev/null +++ b/files/ja/tools/memory/dominators/index.html @@ -0,0 +1,61 @@ +--- +title: ドミネーター +slug: Tools/Memory/Dominators +translation_of: Tools/Memory/Dominators +--- +
{{ToolsSidebar}}
+

本記事では JavaScript のようなガベージコレクションを行う言語に適用される 到達可能性、シャローサイズと 保持サイズ、支配ノードの概念を紹介します。

+ +

オブジェクト自体は小さくても他の大きなオブジェクトを多数参照する場合があり、ガベージコレクターが多くのメモリーを解放できなくなる可能性があることから、この概念はメモリーの分析において重要です。

+ +

メモリーツールの ドミネータービューを使用して、ページ内の支配ノードを確認できます。

+
+ +

JavaScript のようにガベージコレクションを行う言語では、通常プログラマーはメモリーの解放について悩む必要はありません。プログラマーはオブジェクトを作成および使用するだけでよく、オブジェクトが不要になればランタイムがクリーンアップを引き受けて、オブジェクトが占有していたメモリを解放します。

+ +

到達可能性

+ +

現代の JavaScript 実装では、ランタイムは Reachability に基づいてオブジェクトが不要であるかを判断します。このシステムでは、ヒープを 1 つ以上のグラフで表します。グラフ内の各ノードはオブジェクトを表し、ノード (の縁) 同士の接続はあるオブジェクトから別のオブジェクトへの参照を表します。グラフはルートノードから始まります。本記事の図ではルートノードを "R" で示します。

+ +

+ +

ガベージコレクションを行うとき、ランタイムはグラフをルートから走査して、発見したすべてのオブジェクトに印をつけます。発見されないオブジェクトは到達性がないので、解放できます。

+ +

従ってオブジェクトの到達性がなくなると (例えば、スコープから外れたローカル変数1個からしか参照されていないオブジェクト)、そのオブジェクトが参照するオブジェクトも、他のオブジェクトから参照されていなければ到達性がなくなります:

+ +

+ +

逆に、到達性がある他のオブジェクトがそれらを参照し続けている間は、維持され続けることになります。

+ +

シャローサイズと保持サイズ

+ +

この考え方から、オブジェクトのサイズを調べる方法が 2 つに区別されます:

+ + + +

通常、オブジェクトのシャローサイズは小さいのですが、保持サイズは参照により他のオブジェクトを含むために大きくなります。保持サイズは " このオブジェクトが存在しなくなると、メモリーがどれだけ解放されるか？ " という疑問への答えになりますので、メモリー使用量の分析において重要な概念です。

+ +

支配ノード

+ +

関連する概念として支配ノードがあります。ルートノードからノード A に至るすべてのパスがノード B を通るとき、ノード B はノード A を支配すると言います:

+ +

+ +

ノード A の支配ノードのいずれかが解放されると、ノード A 自体はガベージコレクションの対象に適した状態になります。

+ +

ノード B はノード A を支配しているが、ノード A の他の支配ノードが支配していないとき、ノード B はノード A の隣接支配ノードとなります:

+ +

+ +

オブジェクト A が別のオブジェクト B および C から参照されている場合は少々とらえにくいのですが、どちらも A の支配ノードではありません。これは、B または C のどちらかをグラフから削除しても、A は他の参照元によって維持され続けるためです。代わりに A の隣接支配ノードは、最初の共通の祖先になります:
+

+ +

関連情報

+ + diff --git a/files/ja/tools/memory/dominators_view/index.html b/files/ja/tools/memory/dominators_view/index.html new file mode 100644 index 0000000000..de2e20efd6 --- /dev/null +++ b/files/ja/tools/memory/dominators_view/index.html @@ -0,0 +1,154 @@ +--- +title: ドミネータービュー +slug: Tools/Memory/Dominators_view +translation_of: Tools/Memory/Dominators_view +--- +
{{ToolsSidebar}}
+

ドミネータービューは、Firefox 46 の新機能です。

+
+ +

Firefox 46 より、メモリーツールに新たなビューであるドミネータービューが加わりました。これは、サイトによって割り当てられたオブジェクトの " 保持サイズ " を知るのに役立ちます。保持サイズはオブジェクト自身のサイズと、参照によって保持されているオブジェクトのサイズを合算したものです。

+ +

シャローサイズ、保持サイズ、ドミネーターが何かを知っている場合は、ドミネーターの UI のセクションに進んでください。そうでない場合は、ドミネーターの概念の記事でこれらを調べたいと思うかもしれません。

+ +

ドミネータの UI

+ +

" 表示 " のドロップダウンリストで " ドミネーター " を選択すると、ドミネータービューを表示します。以下のようなものです:

+ +

+ +

ドミネータービューは 2 つのパネルで構成されます:

+ + + +

+ +

ドミネーターツリーパネル

+ +

ドミネーターツリーは、スナップショット内でどのオブジェクトがもっとも多くのメモリーを保持しているかを表示します。

+ +

UI のメインエリアで、最初の行が "GC ルート" という名前になっています。この直下に、以下の項目が並びます:

+ + + +

それぞれの項目で、以下の内容を表示します:

+ + + +

項目は、メモリーの保持サイズの大きさ順に並びます。例えば:

+ +

+ +

このスクリーンショットでは、" GC ルート " の配下に項目が 5 つあることがわかります。始めの 2 つは Call オブジェクトと Window オブジェクトであり、それぞれスナップショットの総メモリ量の 21% と 8% を保持しています。また、これらのオブジェクトは " シャローサイズ " が比較的小さく、保持サイズのほぼすべては、支配しているオブジェクト内にあることもわかります。

+ +

各 GC ルートの直下に、そのルートが 隣接支配ノード であるすべてのノードを配置します。これらのノードも、保持サイズ順に並びます。

+ +

例えば、最初の Window オブジェクトをクリックします:

+ +

+ +

この Window は CSS2Properties オブジェクトを支配しており、その保持サイズはスナップショット全体の 2% であることがわかります。やはりシャローサイズはとても小さく、保持サイズのほぼすべてが、支配しているノード内にあります。Function の隣にある展開用の三角印をクリックすると、それらのノードを確認できます。

+ +

この方法で、スナップショット内でどのオブジェクトがもっとも多くのメモリーを保持しているかを、すばやく把握できます。

+ +

Alt + クリックで、ノード配下のグラフ全体を展開できます。

+ +

コールスタック

+ +

ツール上部のツールバーに、"ラベル" という名称のドロップダウンリストがあります:

+ +

+ +

デフォルトでは " Type " に設定されています。一方、これを " Call Stack " に切り替えると、コードの中でオブジェクトを割り当てている場所はどこかを表示します。

+ +
+

Firefox 46 では、このオプションの名称は " Allocation Stack " でした。

+
+ +

ビューを表示するには、オブジェクトを割り当てるコードを実行する前に " コールスタックを記録 " のチェックボックスにチェックを入れなければなりません。そしてスナップショットを採取して、" ラベル " ドロップダウンリストで " Call Stack " を選択します。

+ +

するとノードを割り当てた関数の名前、およびその関数が存在するファイルの名前、行番号、何文字目かをノードの名前に含めて表示します。ファイル名をクリックすると、デバッガーで該当箇所を表示します。

+ +

{{EmbedYouTube("qTF5wCSD124")}}

+ +
+

ここに " (有効なスタックはありません) " と表示される場合があります。特に、現在割り当てスタックはオブジェクトのみ記録しており、配列、文字列、内部構造は記録していません。

+
+ +

保持パスパネル

+ +
保持パスパネルは Firefox 47 の新機能です。
+ +

保持パスパネルではあるノードについて、そのノードから GC ルートに戻る最短パスを 5 つ表示します。これによって、そのノードがガベージコレクションの対象にならないようにしているすべてのノードを知ることができます。オブジェクトがリークしていると思われる場合に、どのオブジェクトが参照を保持しているかを的確に示します。

+ +

ドミネータツリーパネルでノードを選択すると、ノードの保持パスを表示します:

+ +

+ +

ここでは Object を選択しており、GC ルートに戻るパスが 1 つあることがわかります。

+ +

GC ルート Window は HTMLDivElement オブジェクトへの参照を保持しており、またそのオブジェクトが Object への参照を保持しています。ドミネーターツリーパネルを見ると、同じパスをたどることができます。これらの参照のどちらかが削除されると、配下のアイテムはガベージコレクションの対象になるでしょう。

+ +

グラフ内の各接続に、参照されるオブジェクト用の変数の名称がついています。

+ +

ノードから戻る保持パスが複数存在することがあります:

+ +

+ +

この図では、DocumentPrototype ノードから GC ルートに戻るパスが 3 つあります。ひとつが削除されても、ほかのパスが維持されていますので DocumentPrototype はガベージコレクションの対象になりません。

+ +

例

+ +

シンプルなコードがどのようにドミネータービューへ反映されるかを見ていきましょう。

+ +

ここでは monster allocation example を使用します。これは 3 個の配列を生成しており、それぞれに 5,000 体のモンスターが含まれています。また、それぞれのモンスターはランダムに生成された名前を持っています。

+ +

スナップショットを採取する

+ +

これがドミネータービューでどのように見えるかを確認します:

+ + + +

{{EmbedYouTube("HiWnfMoMs2c")}}

+ +

ドミネーターツリーを分析する

+ +

上位 3 件の GC ルートが Array であり、それぞれ総メモリー使用量の約 23% を保持しています:

+ +

+ +

Array を展開すると、含まれているオブジェクト (モンスター) を表示します。それぞれのモンスターは、シャローサイズが 160 バイトと比較的小さくなっています。これは、目の数と触手の数の整数値を含んでいます。また各モンスターの保持サイズは大きく、これはモンスターの名前の文字列が占めています:

+ +

+ +

これらはすべて、予想したメモリーグラフ に近い形で並んでいます。しかし、ひとつ不思議に思う点があるでしょう。3 つの Array を保持するトップレベルオブジェクトはどこにあるのでしょうか？ ある Array の保持パスを確認すると、以下のようになっているでしょう:

+ +

+ +

ここでは保持するオブジェクトが見えており、またオブジェクト固有の Array は fierce モンスターの Array です。しかし Array はルートでもあるため、オブジェクトが Array を参照しなくなってもガベージコレクションの対象にはならないでしょう。

+ +

これはオブジェクトが Array を支配していないため、ドミネータツリービューに表示されないということです。ドミネータの概念の記事で関連する章をご覧ください。

+ +

コールスタックビューを使用する

+ +

最後に、Call Stack ビューへ切り替えると、オブジェクトがどこで割り当てられたかを確認できます。また、デバッガーでその場所にジャンプできます:

+ +

{{EmbedYouTube("qTF5wCSD124")}}

diff --git a/files/ja/tools/memory/index.html b/files/ja/tools/memory/index.html new file mode 100644 index 0000000000..5ead5856b4 --- /dev/null +++ b/files/ja/tools/memory/index.html @@ -0,0 +1,65 @@ +--- +title: メモリー +slug: Tools/Memory +tags: + - DevTools + - Firefox + - Mozilla + - Tools +translation_of: Tools/Memory +--- +
{{ToolsSidebar}}

メモリーツールを使用して、カレントタブのメモリー ヒープ のスナップショットを取得できます。そして、どのオブジェクトがどれだけメモリーを使用しているかや、コードのどこでメモリーを割り当てているかを表示可能な、ヒープのさまざまなビューを提供します。

+ +

{{EmbedYouTube("DJLoq5E5ww0")}}

+ +
+

基礎

+ +
+ +
+ +
+

スナップショットを分析する

+ +
+

ツリーマップビューは Firefox 48 の新機能、ドミネータービューは Firefox 46 の新機能です。

+
+ +

スナップショットを採取すると、メモリーツールは 3 つの主要なビューを提供します:

+ + + +

スナップショットで割り当てスタックの記録を有効にすると、コードのどこで割り当てが行われたかを総計ビューとドミネータービューで表示できます。

+ +
+

概念

+ +
+ +
+ +
+

サンプルページ

+ +

メモリーツールのドキュメントで使用しているサンプルです。

+ +
+ +
diff --git a/files/ja/tools/memory/monster_example/index.html b/files/ja/tools/memory/monster_example/index.html new file mode 100644 index 0000000000..3458550a5f --- /dev/null +++ b/files/ja/tools/memory/monster_example/index.html @@ -0,0 +1,81 @@ +--- +title: Monster example +slug: Tools/Memory/Monster_example +translation_of: Tools/Memory/Monster_example +--- +
{{ToolsSidebar}}

この記事では、メモリツールの機能を示すために使用するシンプルなページについて説明します。

+ +

これは https://mdn.github.io/performance-scenarios/js-allocs/alloc.html で試すことができます。コードは以下のとおりです:

+ +
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);
+ +

このページにはボタンがあります。このボタンを押すと、コードがモンスターを生成します。詳細は以下のとおりです:

+ + + +

従って、JavaScript のヒープ上に割り当てられるメモリの構造は、3 つの配列を持つオブジェクトになります。それぞれの配列は 5000 個のオブジェクト (モンスター) を持ち、そのオブジェクトが文字列と 2 つの数値を持ちます:

+ +

diff --git a/files/ja/tools/memory/tree_map_view/index.html b/files/ja/tools/memory/tree_map_view/index.html new file mode 100644 index 0000000000..2001846a58 --- /dev/null +++ b/files/ja/tools/memory/tree_map_view/index.html @@ -0,0 +1,45 @@ +--- +title: ツリーマップビュー +slug: Tools/Memory/Tree_map_view +translation_of: Tools/Memory/Tree_map_view +--- +
{{ToolsSidebar}}
+

ツリーマップビューは、Firefox 48 の新機能です。

+
+ +

ツリーマップビューはスナップショットを視覚的に表現して、どのオブジェクトがもっとも多くのメモリを使用しているかの見解をすばやく得る助けになります。

+ +

ツリーマップは、"入れ子の長方形で表現した階層型 (木構造) のデータ" を表示します。長方形のサイズは、データの量的な比率に対応します。

+ +

メモリツールのツリーマップは、ヒープの内容物をトップレベルで 4 つのカテゴリに分類します:

+ + + +

それぞれのカテゴリを長方形で表現して、長方形のサイズはカテゴリ内のアイテムがヒープ内で占める割合に対応します。よって、あなたのサイトでどの種類のものがもっとも多くのメモリを使用しているかについて、おおまかな見解をすばやく得ることができます。

+ +

トップレベルのカテゴリ内では、以下のように分割します:

+ + + +

こちらが、ツリーマップビューで表示したスナップショットのサンプルです:

+ +

+ +

このツリーマップは DOM allocation example で取得しました。このページは大量の DOM ノード (200 個の HTMLDivElement オブジェクトと 4000 個の HTMLSpanElement オブジェクト) を生成するスクリプトを実行します。ヒープのほとんどすべてが、スクリプトで生成した HTMLSpanElement オブジェクトであることがわかります。

+ +

+ +

このツリーマップは、monster allocation example で取得しました。これは 3 個の配列を生成しており、それぞれに 5000 体のモンスターが含まれています。また、それぞれのモンスターはランダムに生成された名前を持っています。ヒープのほとんどがモンスターの名前で使用する文字列と、モンスターの他の属性を収めるために使用するオブジェクトで占められていることがわかります。

+ +

+ +

このツリーマップは http://www.bbc.com/ で取得しました。前出のサンプルより現実的な見本であるといえるでしょう。ヒープの多くがスクリプトで占められており、それらは多数の生成元から読み込まれていることがわかります。

-- cgit v1.2.3-54-g00ecf