16

を使用して Ember オブジェクトを作成してみました

c = Em.Object.create();

メモリダンプをチェックしてこれを確認しました

ここに画像の説明を入力

これは、24 の浅いメモリと 524 の保持メモリを示唆しています。私の質問は、コントローラにそのような Ember オブジェクトを約 500 個保持している場合、これはメモリに関して心配することでしょうか。

たとえば、配列に 500 個の Ember オブジェクトを持つコントローラーがあるとしcontentます。この場合、moory ダンプは次のようになります。

ここに画像の説明を入力

ここでは、配列内の各項目の保持サイズは 524 であり、その結果、コントローラーの保持サイズは 268088 と大きくなります。これは本当に問題ですか?

すべての Ember オブジェクトが、それぞれが参照する共通オブジェクトの同じ 524 バイトを参照しているかどうかは疑問です。

4

2 に答える 2

35

わかりました、ついにEmberソースをよく見て、それを理解しました。を使用してdeleteいるからです。

(Emberは現在これを修正しており、空白の ember オブジェクトによる劇的なメモリ使用はもうないはずです。 )

deleteV8 に「このオブジェクトを実際のオブジェクトではなくハッシュ マップのように使用する」ことを伝え、したがって、ファウンデーション モダンのコア機能である「C 構造体」のような構造ではなく、内部ハッシュ マップ構造に切り替えてプロパティを格納します。 JavaScriptのパフォーマンスが構築されています。

灰色の を見るpropertiesと、ハッシュテーブルである内部ストレージが占めるスペースを意味するため、多くのスペースが必要です。

私はjsfiddleを作成しました:

http://jsfiddle.net/JSbMJ/

ヒープ スナップショットを実行してオブジェクトを探し、それらのサイズがどれほど大きく異なるか (472 対 80) を確認する必要があります。

ここに画像の説明を入力

ここに画像の説明を入力

ただし、ゲームや物理シミュレーションなどではなく、残り火で CRUD を実行することになっているため、これはまったく問題ではありません。

ところで、他のエンジンがそのような反応をしているかどうかはわかりませんがdelete、意味的にオブジェクトを持っている場合、そのような操作は意味がなく、多くの言語では不可能であるため、そうであると思います。

于 2013-08-18T00:06:31.240 に答える