元スレ+ JavaScript の質問用スレッド vol.128 +

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

51 = :

>>25
見落としがあるかと思って探しましたが
一般のPerformance API群にそんな機能ないですね

Chromeのみに入ってるPerformance.memoryのことでしたら
これはプロセス別の正確な使用メモリは取れません
ですのでchromium系の場合chrome:memoryや開発者ツールのが有用になります

52 = :

>>51
ちな目的は？

53 = :

>>51
それは間違い。
performance.memoryはプロセス別のメモリを返す。
問題は１プロセス＝１ページとは限らないということ。
とは言えopenerが存在する場合のように、ページ同士に相互通信ができる特殊な場合にしかまとめられないので、
基本的に１ページの値を返すと思って良い。

54 = :

>>52
改めて問われると難しいですが
(DOMツリー含む)メモリ使用量平均の低減とstoptheworldの防止ですね

55 = :

>>51
開発ツールでの測定とperformance.memoryの示す値は同じだよ
開発ツールでもプロセス内の他タブの影響も受ける
ただしそれは良いことで、タブを閉じた後、別タブからの参照のため
メモリリークが起こっているのを発見できる

57 = :

>>55
言葉足らずでした
開発者ツールは詳細が表示されるので正確に見れます

>ただしそれは良いことで、タブを閉じた後、別タブからの参照のため
>メモリリークが起こっているのを発見できる
これは良くわかりません、どういう事ですか？
閉じたらプロファイル消えると思いますが
Chromeではなく他のブラウザの話ですか？

59 = :

>>57
プロファイルを開いているタブ以外を閉じたときの話だよ
それと詳細とは言ってもJSヒープについてタブの区別はない
あと前提条件として開発ツールは使えないという話だったのに、
そっちの方が良いってどういうこと？

60 = :

>>59
理解できました
タブを閉じてもメモリが減らない事を見るという意味ですね

>あと前提条件として開発ツールは使えないという話だったのに、
>そっちの方が良いってどういうこと？
使えないのは自分の環境の問題で、後者は飽くまで正確性の話です
それぞれ別の論点です

61 = :

これ以上関係ない議論するのは迷惑になりそうなので、そろそろ去ります
レスをくれた方、ありがとうございました
XeonのPCでも買います

62 = :

去る前に間違った知識を改めなさい。
正確性とか言い出したら、そもそもJSHeapと実メモリのアロケーションは関係ないし、
一部の大きなバッファはJSHeapと独立して管理されて反映されないものもある。

63 = :

終わりかけてる話題に横槍いれる形で申し訳ないんだけど
現実問題として、変数にnullを代入することの負荷、とくに使用CPUと消費メモリの遷移はどうやって調べるのが正しいの
そもそもnull代入がメモリを食うのかについても気になる

64 = :

null代入する事に寄る負荷はほぼ無いよ、ただのポインタクリアだし、n=m+1と何ら変わらん
参照カウンタを失ってGCが発生する事に寄る負荷の方がそれに比べたら遙かにでかい

66 = :

function hoge1 () { var a = 'sample'; }
function hoge2 () { var a = 'sample'; a = null; }
hoge1();
hoge2();

hoge2 の null 代入に意味を見出せないのだが、認識合ってる？
どちらにしろ GC で開放する事に変わりは無いので hoge1 で十分だと思うのだが

67 = :

>>66
aが単なる変数である場合には関数終了時に意図した通りにGCされるからnull代入する必要はないね
aがオブジェクトでその中で外側の変数を参照してたり循環参照してる場合
明示的にnullを代入する事で参照を切り、メモリリークを防止する意味がある

68 = :

>>67
ありがとう、安心した
外側の変数を参照しているケースは良く見るな
特にaddEventListener系だが、無名関数を使うのが定型だと思い込んでいる人のなんと多い事か

function hoge () {
var p = document.getElementById('p');
p.addEventListener('click', function () { console.log('sample'); }, false);
}

70 = :

無名関数で指定したらremoveどうするの？

71 = :

関数のスコープ内ではそもそも外からは中の変数アクセス出来ないし、
for (var i = 0; i < 100; i++) {}
console.log(i); //100
なんかも結局そのあとにまた同じような処理をするときに、
for (var i = 0; i < 100; i++) {}
for (var i = 0; i < 10; i++) {}
console.log(i); //10
って変数初期化するし、いまいちletの用法が・・・わからない！

72 = :

for (let i = 0; i < 100; i++) {
for (let i = 0; i < 10; i++) {}
}
みたいにする時と
for (let i = 0; i < 10; i++) {
setTimeout(()=>console.log(i))
}
みたいにする時に価値がある

73 = :

Chromeでのみ
o = {__proto__:new Int8Array(1)};
Object.prototype[1.5] = 1.5;
o[1.5]; //undefined
がundefinedとなるのはどうしてですか？

74 = :

>>72のネストのケースって最初のiも2つめのループ中で使いたい時多いんじゃ
var i var jでいいよね

75 = :

>>74
それでもいいけど、スコープを厳密に区切れるのは let の利点。

let array = [[1, true], [2, false], [3, true]];
for (let i = 0, l = array.length; i < l; ++i) {
let array2 = array[i];
for (let i = 0, l = array2.length; i < l; ++i) {
console.log(array2[i]);
}
}

77 = :

>>75
さすがにわかりにくいｗ

78 = :

コード設計を考えるときに var だと関数スコープだから他の変数と衝突しないように名前管理する必要があって面倒に感じる事はある
一次変数は全て let で定義すれば管理がとても楽

79 = :

>>77
二次元配列の処理としては定型だと思うけど(var でも似たような処理がよくあるし)

80 = :

＞var だと関数スコープだから他の変数と衝突しないように
forループに限って言えばi,j,k...と使う暗黙のルールあるし問題ないけどね。
例えばtmpとか衝突しても問題ないような名前にしてたり、
管理面では特にletに置き換える必要性はないかな。
http://developer.mozilla.org/ja/docs/Web/JavaScript/Closures
こういう時に使うのが実用的なんだと思う。

81 = :

2次元配列の定形は、i, j を使う方法だろ。

var array = [[1, true], [2, false], [3, true]];
for (var i = 0; i < array.length; i++) {
　　for (var j = 0; j < array[i].length; j++) {
　　　　console.log(array[i, j]);
　　}
}

82 = :

・クロージャとかほんとに必要な場面以外ならば使わないで済むならそれがわかりやすい
・ありがちな i を別のループでうっかり使っちゃって無限ループなんてことがないからletが良い
どっちも利点はあるから他のメンバーと好みで決定

83 = :

letのほうが最先端みたいでかっこいいからlet使いたいだけだ（ｷﾘｯ

84 = :

>>80
一次変数はループ変数に限らず、for文内でしか使わない変数は他にもある
全部、tmp なんて数が増えたら tmp1, tmp2 なんて命名してやってられないし、tmp では中身分からない名前なので関数スコープで命名する利点もない
あと、「スコープを可能な限り狭く」は原則だから必要ないブロック外までスコープが漏れているのは美しくないと思う

>>81
それはさすがにあなたの観測範囲が狭いだけだと思うな

85 = :

tmpは使い捨てなんだからtmp1 tmp2なんてやらないだろｗ
>「スコープを可能な限り狭く」は原則だから必要ないブロック外までスコープが漏れているのは美しくないと思う
元々letなんてなかったのに

86 = :

ある種の問題の解決のためにletが使われるという話ならいいんだけど
>>84の言い分じゃletにする理由としてはいまいちなんだよな

87 = :

letの長所は使った事のある人にしか分からないだろうな

88 = :

C言語とか、ブロックスコープに慣れ親しんでいる人からするとJavaScriptのfor(var i=0;...)があり得ない挙動だから>>84に共感しそうな気もするが、まあ感覚の違いだな
頭の中で想定するスコープの設計概念がまるで違うからvarで慣れている人からしたらどうでもいい事に思えるのだろう

89 = :

>>84
なんだ観測範囲ってｗ
意味不明すぎる。

90 = :

>>87
> letの長所は使った事のある人にしか分からないだろうな
使ったことあるけど、やはり意味ないよ。
なぜなら俺は関数を小さく保つからね。
綺麗なコードを書いているとletを使う必要性はほとんど無くなる。

92 = :

で、どっちがコスト低いの？

93 = :

>>81
それをletの定型にしたコードが>>75なのでは？

94 :

関数コードを小さくまとめるのは勿論しているけど、それでも変数の数が10を越える辺りからやや管理が面倒になる
同じプロパティを2回参照する時には変数にキャッシュするとか、パフォーマンス寄りに設計することもあって変数の数が多くなりがちだから
Array.prototype.forEach 系を封印している(Statementと比較してパフォーマンスが良くない)のも変数が増える理由の一つ
では、更に関数を小分けにすればいいかというと単機能関数を更に分割する事になって管理上、都合がよろしくない(関数管理コストが現状の変数管理コストを上回る)
現状でも変数管理は出来ているから急を要する問題ではないけど、「let を使えれば変数管理が楽になるのに」とは良く思う
この辺りは設計思想の違いだろうから共感できない人も多そうだけどね
一般的にはおそらく、>>90が挙げるような下位スコープに波及しない let の動作に魅力を感じる人が多いだろうね

95 = 94 :

ごめん、レスアンカー先を間違えた

×　一般的にはおそらく、>>90が挙げるような下位スコープに波及しない let の動作に魅力を感じる人が多いだろうね
○　一般的にはおそらく、>>80が挙げるような下位スコープに波及しない let の動作に魅力を感じる人が多いだろうね

96 = :

>>94
早過ぎる最適化は、コードの可読性を落とすので
必要にならないかぎりやらないほうがいい。

forEach系を封印しているというのが頭固い証拠で
明らかに早過ぎる最適化をするための悪いルールだ。

そのせいで変数の管理コストという問題が実際にでてるのだろう？
自業自得だ。

97 = :

本人はlet使えば解決するといっているから好きにさせればいいのになぜそこまで執拗に否定するんだろう？

98 = :

>>18と>>96はいつもの(無自覚な)荒らしだから

99 = :

「letを使えば関数初頭のローカル変数の数を減らせる」
この事実をメリットととるか否かはただの思想の違い
絶対解がある問題でもない

100 = :

> 「letを使えば関数初頭のローカル変数の数を減らせる」
これはどういうことかすら