私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.128 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>25
見落としがあるかと思って探しましたが
一般のPerformance API群にそんな機能ないですね
Chromeのみに入ってるPerformance.memoryのことでしたら
これはプロセス別の正確な使用メモリは取れません
ですのでchromium系の場合chrome:memoryや開発者ツールのが有用になります
見落としがあるかと思って探しましたが
一般のPerformance API群にそんな機能ないですね
Chromeのみに入ってるPerformance.memoryのことでしたら
これはプロセス別の正確な使用メモリは取れません
ですのでchromium系の場合chrome:memoryや開発者ツールのが有用になります
>>51
ちな目的は？
ちな目的は？
>>51
それは間違い。
performance.memoryはプロセス別のメモリを返す。
問題は１プロセス＝１ページとは限らないということ。
とは言えopenerが存在する場合のように、ページ同士に相互通信ができる特殊な場合にしかまとめられないので、
基本的に１ページの値を返すと思って良い。
それは間違い。
performance.memoryはプロセス別のメモリを返す。
問題は１プロセス＝１ページとは限らないということ。
とは言えopenerが存在する場合のように、ページ同士に相互通信ができる特殊な場合にしかまとめられないので、
基本的に１ページの値を返すと思って良い。
>>51
開発ツールでの測定とperformance.memoryの示す値は同じだよ
開発ツールでもプロセス内の他タブの影響も受ける
ただしそれは良いことで、タブを閉じた後、別タブからの参照のため
メモリリークが起こっているのを発見できる
開発ツールでの測定とperformance.memoryの示す値は同じだよ
開発ツールでもプロセス内の他タブの影響も受ける
ただしそれは良いことで、タブを閉じた後、別タブからの参照のため
メモリリークが起こっているのを発見できる
>>55
言葉足らずでした
開発者ツールは詳細が表示されるので正確に見れます
>ただしそれは良いことで、タブを閉じた後、別タブからの参照のため
>メモリリークが起こっているのを発見できる
これは良くわかりません、どういう事ですか？
閉じたらプロファイル消えると思いますが
Chromeではなく他のブラウザの話ですか？
言葉足らずでした
開発者ツールは詳細が表示されるので正確に見れます
>ただしそれは良いことで、タブを閉じた後、別タブからの参照のため
>メモリリークが起こっているのを発見できる
これは良くわかりません、どういう事ですか？
閉じたらプロファイル消えると思いますが
Chromeではなく他のブラウザの話ですか？
すみませんまた言葉足らずでした
chromeではなく(chroimum系の)他のブラウザの話ですか？
chromeではなく(chroimum系の)他のブラウザの話ですか？
>>57
プロファイルを開いているタブ以外を閉じたときの話だよ
それと詳細とは言ってもJSヒープについてタブの区別はない
あと前提条件として開発ツールは使えないという話だったのに、
そっちの方が良いってどういうこと？
プロファイルを開いているタブ以外を閉じたときの話だよ
それと詳細とは言ってもJSヒープについてタブの区別はない
あと前提条件として開発ツールは使えないという話だったのに、
そっちの方が良いってどういうこと？
>>59
理解できました
タブを閉じてもメモリが減らない事を見るという意味ですね
>あと前提条件として開発ツールは使えないという話だったのに、
>そっちの方が良いってどういうこと？
使えないのは自分の環境の問題で、後者は飽くまで正確性の話です
それぞれ別の論点です
理解できました
タブを閉じてもメモリが減らない事を見るという意味ですね
>あと前提条件として開発ツールは使えないという話だったのに、
>そっちの方が良いってどういうこと？
使えないのは自分の環境の問題で、後者は飽くまで正確性の話です
それぞれ別の論点です
これ以上関係ない議論するのは迷惑になりそうなので、そろそろ去ります
レスをくれた方、ありがとうございました
XeonのPCでも買います
レスをくれた方、ありがとうございました
XeonのPCでも買います
去る前に間違った知識を改めなさい。
正確性とか言い出したら、そもそもJSHeapと実メモリのアロケーションは関係ないし、
一部の大きなバッファはJSHeapと独立して管理されて反映されないものもある。
正確性とか言い出したら、そもそもJSHeapと実メモリのアロケーションは関係ないし、
一部の大きなバッファはJSHeapと独立して管理されて反映されないものもある。
終わりかけてる話題に横槍いれる形で申し訳ないんだけど
現実問題として、変数にnullを代入することの負荷、とくに使用CPUと消費メモリの遷移はどうやって調べるのが正しいの
そもそもnull代入がメモリを食うのかについても気になる
現実問題として、変数にnullを代入することの負荷、とくに使用CPUと消費メモリの遷移はどうやって調べるのが正しいの
そもそもnull代入がメモリを食うのかについても気になる
null代入する事に寄る負荷はほぼ無いよ、ただのポインタクリアだし、n=m+1と何ら変わらん
参照カウンタを失ってGCが発生する事に寄る負荷の方がそれに比べたら遙かにでかい
参照カウンタを失ってGCが発生する事に寄る負荷の方がそれに比べたら遙かにでかい
Rubyなら、GC.start,
ObjectSpace.count_objects などで、
ガベージ時のオブジェクトの数を数えるけど
ObjectSpace.count_objects などで、
ガベージ時のオブジェクトの数を数えるけど
function hoge1 () { var a = 'sample'; }
function hoge2 () { var a = 'sample'; a = null; }
hoge1();
hoge2();
hoge2 の null 代入に意味を見出せないのだが、認識合ってる？
どちらにしろ GC で開放する事に変わりは無いので hoge1 で十分だと思うのだが
function hoge2 () { var a = 'sample'; a = null; }
hoge1();
hoge2();
hoge2 の null 代入に意味を見出せないのだが、認識合ってる？
どちらにしろ GC で開放する事に変わりは無いので hoge1 で十分だと思うのだが
>>66
aが単なる変数である場合には関数終了時に意図した通りにGCされるからnull代入する必要はないね
aがオブジェクトでその中で外側の変数を参照してたり循環参照してる場合
明示的にnullを代入する事で参照を切り、メモリリークを防止する意味がある
aが単なる変数である場合には関数終了時に意図した通りにGCされるからnull代入する必要はないね
aがオブジェクトでその中で外側の変数を参照してたり循環参照してる場合
明示的にnullを代入する事で参照を切り、メモリリークを防止する意味がある
>>67
ありがとう、安心した
外側の変数を参照しているケースは良く見るな
特にaddEventListener系だが、無名関数を使うのが定型だと思い込んでいる人のなんと多い事か
function hoge () {
var p = document.getElementById('p');
p.addEventListener('click', function () { console.log('sample'); }, false);
}
ありがとう、安心した
外側の変数を参照しているケースは良く見るな
特にaddEventListener系だが、無名関数を使うのが定型だと思い込んでいる人のなんと多い事か
function hoge () {
var p = document.getElementById('p');
p.addEventListener('click', function () { console.log('sample'); }, false);
}
setTimeoutやforEachなど、コールバック関数は無名関数で指定するものと固定観念を持っている人は結構いるよね
関数のスコープ内ではそもそも外からは中の変数アクセス出来ないし、
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の用法が・・・わからない！
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の用法が・・・わからない！
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))
}
みたいにする時に価値がある
for (let i = 0; i < 10; i++) {}
}
みたいにする時と
for (let i = 0; i < 10; i++) {
setTimeout(()=>console.log(i))
}
みたいにする時に価値がある
Chromeでのみ
o = {__proto__:new Int8Array(1)};
Object.prototype[1.5] = 1.5;
o[1.5]; //undefined
がundefinedとなるのはどうしてですか？
o = {__proto__:new Int8Array(1)};
Object.prototype[1.5] = 1.5;
o[1.5]; //undefined
がundefinedとなるのはどうしてですか？
>>72のネストのケースって最初のiも2つめのループ中で使いたい時多いんじゃ
var i var jでいいよね
var i var jでいいよね
>>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]);
}
}
それでもいいけど、スコープを厳密に区切れるのは 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]);
}
}
>>75
さすがにわかりにくいｗ
さすがにわかりにくいｗ
コード設計を考えるときに var だと関数スコープだから他の変数と衝突しないように名前管理する必要があって面倒に感じる事はある
一次変数は全て let で定義すれば管理がとても楽
一次変数は全て let で定義すれば管理がとても楽
>>77
二次元配列の処理としては定型だと思うけど(var でも似たような処理がよくあるし)
二次元配列の処理としては定型だと思うけど(var でも似たような処理がよくあるし)
＞var だと関数スコープだから他の変数と衝突しないように
forループに限って言えばi,j,k...と使う暗黙のルールあるし問題ないけどね。
例えばtmpとか衝突しても問題ないような名前にしてたり、
管理面では特にletに置き換える必要性はないかな。
http://developer.mozilla.org/ja/docs/Web/JavaScript/Closures
こういう時に使うのが実用的なんだと思う。
forループに限って言えばi,j,k...と使う暗黙のルールあるし問題ないけどね。
例えばtmpとか衝突しても問題ないような名前にしてたり、
管理面では特にletに置き換える必要性はないかな。
http://developer.mozilla.org/ja/docs/Web/JavaScript/Closures
こういう時に使うのが実用的なんだと思う。
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]);
}
}
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]);
}
}
・クロージャとかほんとに必要な場面以外ならば使わないで済むならそれがわかりやすい
・ありがちな i を別のループでうっかり使っちゃって無限ループなんてことがないからletが良い
どっちも利点はあるから他のメンバーと好みで決定
・ありがちな i を別のループでうっかり使っちゃって無限ループなんてことがないからletが良い
どっちも利点はあるから他のメンバーと好みで決定
letのほうが最先端みたいでかっこいいからlet使いたいだけだ（ｷﾘｯ
tmpは使い捨てなんだからtmp1 tmp2なんてやらないだろｗ
>「スコープを可能な限り狭く」は原則だから必要ないブロック外までスコープが漏れているのは美しくないと思う
元々letなんてなかったのに
>「スコープを可能な限り狭く」は原則だから必要ないブロック外までスコープが漏れているのは美しくないと思う
元々letなんてなかったのに
ある種の問題の解決のためにletが使われるという話ならいいんだけど
>>84の言い分じゃletにする理由としてはいまいちなんだよな
>>84の言い分じゃletにする理由としてはいまいちなんだよな
C言語とか、ブロックスコープに慣れ親しんでいる人からするとJavaScriptのfor(var i=0;...)があり得ない挙動だから>>84に共感しそうな気もするが、まあ感覚の違いだな
頭の中で想定するスコープの設計概念がまるで違うからvarで慣れている人からしたらどうでもいい事に思えるのだろう
頭の中で想定するスコープの設計概念がまるで違うからvarで慣れている人からしたらどうでもいい事に思えるのだろう
>>87
> letの長所は使った事のある人にしか分からないだろうな
使ったことあるけど、やはり意味ないよ。
なぜなら俺は関数を小さく保つからね。
綺麗なコードを書いているとletを使う必要性はほとんど無くなる。
> letの長所は使った事のある人にしか分からないだろうな
使ったことあるけど、やはり意味ないよ。
なぜなら俺は関数を小さく保つからね。
綺麗なコードを書いているとletを使う必要性はほとんど無くなる。
>>70
Non Strict Modeならarguments.callerで再帰処理できるが、無名関数を指定する人の多くはremoveEventListenerする事を考えてない
Non Strict Modeならarguments.callerで再帰処理できるが、無名関数を指定する人の多くはremoveEventListenerする事を考えてない
関数コードを小さくまとめるのは勿論しているけど、それでも変数の数が10を越える辺りからやや管理が面倒になる
同じプロパティを2回参照する時には変数にキャッシュするとか、パフォーマンス寄りに設計することもあって変数の数が多くなりがちだから
Array.prototype.forEach 系を封印している(Statementと比較してパフォーマンスが良くない)のも変数が増える理由の一つ
では、更に関数を小分けにすればいいかというと単機能関数を更に分割する事になって管理上、都合がよろしくない(関数管理コストが現状の変数管理コストを上回る)
現状でも変数管理は出来ているから急を要する問題ではないけど、「let を使えれば変数管理が楽になるのに」とは良く思う
この辺りは設計思想の違いだろうから共感できない人も多そうだけどね
一般的にはおそらく、>>90が挙げるような下位スコープに波及しない let の動作に魅力を感じる人が多いだろうね
同じプロパティを2回参照する時には変数にキャッシュするとか、パフォーマンス寄りに設計することもあって変数の数が多くなりがちだから
Array.prototype.forEach 系を封印している(Statementと比較してパフォーマンスが良くない)のも変数が増える理由の一つ
では、更に関数を小分けにすればいいかというと単機能関数を更に分割する事になって管理上、都合がよろしくない(関数管理コストが現状の変数管理コストを上回る)
現状でも変数管理は出来ているから急を要する問題ではないけど、「let を使えれば変数管理が楽になるのに」とは良く思う
この辺りは設計思想の違いだろうから共感できない人も多そうだけどね
一般的にはおそらく、>>90が挙げるような下位スコープに波及しない let の動作に魅力を感じる人が多いだろうね
>>94
早過ぎる最適化は、コードの可読性を落とすので
必要にならないかぎりやらないほうがいい。
forEach系を封印しているというのが頭固い証拠で
明らかに早過ぎる最適化をするための悪いルールだ。
そのせいで変数の管理コストという問題が実際にでてるのだろう？
自業自得だ。
早過ぎる最適化は、コードの可読性を落とすので
必要にならないかぎりやらないほうがいい。
forEach系を封印しているというのが頭固い証拠で
明らかに早過ぎる最適化をするための悪いルールだ。
そのせいで変数の管理コストという問題が実際にでてるのだろう？
自業自得だ。
本人はlet使えば解決するといっているから好きにさせればいいのになぜそこまで執拗に否定するんだろう？
「letを使えば関数初頭のローカル変数の数を減らせる」
この事実をメリットととるか否かはただの思想の違い
絶対解がある問題でもない
この事実をメリットととるか否かはただの思想の違い
絶対解がある問題でもない
> 「letを使えば関数初頭のローカル変数の数を減らせる」
これはどういうことかすら
これはどういうことかすら
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.125 + (1001) - [97%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.108 + (1001) - [97%] - 2013/9/21 15:16
- + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.120 + (1002) - [97%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.129 + (981) - [97%] - 2016/5/5 8:16
- + JavaScript の質問用スレッド vol.129 + (926) - [97%] - 2017/7/27 13:45
- + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.127 + (1001) - [97%] - 2016/2/4 0:15
- + JavaScript の質問用スレッド vol.127 + (160) - [97%] - 2021/7/16 9:30
- + JavaScript の質問用スレッド vol.126 + (952) - [97%] - 2015/11/18 13:15
- + JavaScript の質問用スレッド vol.126 + (348) - [97%] - 2023/1/12 17:00
トップメニューへ / →のくす牧場書庫について