私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.118 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
jqueryもキャッシュすればほとんど問題ないよ
オブジェクトを使い捨てにするのがまずい
オブジェクトを使い捨てにするのがまずい
jqueryには端末間の差違を吸収するという役割があるんだから
使うのをやめるという発想はナンセンス
オブジェクトをキャッシュするだけで全然変わるんだから単にそうすればいいだけ
使うのをやめるという発想はナンセンス
オブジェクトをキャッシュするだけで全然変わるんだから単にそうすればいいだけ
>>252-253
では、問題ないと分かる比較コードを上げてみて
では、問題ないと分かる比較コードを上げてみて
オブジェクトを作った時に遅くなるのは
オブジェクトを作るコストであって、
GCは関係ないだろｗ
オブジェクトを作るコストであって、
GCは関係ないだろｗ
>>253
> jqueryには端末間の差違を吸収するという役割があるんだから
そんなのjQueryの役割のうち
ごく小さい部分でしか無いよ。
jQueryの凄さは要素をリストに置き換えて
リスト処理できるようにしたところにある。
> jqueryには端末間の差違を吸収するという役割があるんだから
そんなのjQueryの役割のうち
ごく小さい部分でしか無いよ。
jQueryの凄さは要素をリストに置き換えて
リスト処理できるようにしたところにある。
ちなみにどういうコードかというと、
GCあり
1. オブジェクトを200000個作成して配列に入れる
2. 開始時刻を記録
3. 配列にnullを代入
4. 終了時刻を記録
5. 終了時刻と開始時刻の差を表示
GCなし
1. オブジェクトを200000個作成して配列に入れる
2. 開始時刻を記録
3. 終了時刻を記録
4. 終了時刻と開始時刻の差を表示
この差。
GCあり
1. オブジェクトを200000個作成して配列に入れる
2. 開始時刻を記録
3. 配列にnullを代入
4. 終了時刻を記録
5. 終了時刻と開始時刻の差を表示
GCなし
1. オブジェクトを200000個作成して配列に入れる
2. 開始時刻を記録
3. 終了時刻を記録
4. 終了時刻と開始時刻の差を表示
この差。
たった一回GCが起きたからって違いなんて
計測できるわけじゃないんｗ
計測できるわけじゃないんｗ
だよなぁ。GCのコストなんてごく僅かなのに
何を気にしてるんだろう？
それよりももっと気にするべき所があるだろ。
何を気にしてるんだろう？
それよりももっと気にするべき所があるだろ。
・インターバルで関数を呼び出し続ける
・その関数は内部で巨大なオブジェクトを作る
・一方は作成後破棄し、一方は保持し続ける
この二つを比較したらGCによる遅延を確認できるんじゃね
というか、googleのS級技術者が速くても10msオーダー、
遅い時には1sオーダー処理が停止するって言ってんのに
何を根拠にそれに疑問を持つんだ？？
俺の体感でもそのくらいだなって思うし、
D級プログラマーの疑問のポイントが理解できんわ
・その関数は内部で巨大なオブジェクトを作る
・一方は作成後破棄し、一方は保持し続ける
この二つを比較したらGCによる遅延を確認できるんじゃね
というか、googleのS級技術者が速くても10msオーダー、
遅い時には1sオーダー処理が停止するって言ってんのに
何を根拠にそれに疑問を持つんだ？？
俺の体感でもそのくらいだなって思うし、
D級プログラマーの疑問のポイントが理解できんわ
>>257
おまえの自説の正しさを証明するために決まってるだろ
無根拠にjQueryは問題ないといわれても信用できんわ
わかりきった話で言えば、jQueryの方がコストが高いことはわかりきってるんだからテストする必要はないがな
おまえの自説の正しさを証明するために決まってるだろ
無根拠にjQueryは問題ないといわれても信用できんわ
わかりきった話で言えば、jQueryの方がコストが高いことはわかりきってるんだからテストする必要はないがな
google I/Oのレポートを読んで、
B級以上のプログラマーは
「GCをなるべく起こさないコードを書くにはどうしたらいいのか」
っていう生産的な議論を始めるものだが
C級以下のプログラマーは
「GCなんてたいしたことない！そもそも起こらない！1％！」
とか言い出すから本当にどうしようもない
B級以上のプログラマーは
「GCをなるべく起こさないコードを書くにはどうしたらいいのか」
っていう生産的な議論を始めるものだが
C級以下のプログラマーは
「GCなんてたいしたことない！そもそも起こらない！1％！」
とか言い出すから本当にどうしようもない
まだやってんの？ｗ
俺が最初にネタでGCいいだしたんだけど
一体何時間無駄な時間費やしてるの？
俺が最初にネタでGCいいだしたんだけど
一体何時間無駄な時間費やしてるの？
http://www.html5rocks.com/ja/tutorials/memory/effectivemanagement/
読んだが、当たり前の事しかないてないぞ
・キャッシュは最小限にする(無駄な部分はGCで開放しておく)
・メモリリークは起こさない(同上)
・メモリアロケートを最小限にする(何度も呼ばれるデータはキャッシュしておく)
無条件にGCが悪だとはどこにも書いてない
ケースバイケースでGCを有効活用しようってことだろ
>>234-235あたりが的を射ている意見だと思うがな
これを読んで「GCを出来るだけ発生させないように」と結論するのは「木を見て森を見ず」だろ
読んだが、当たり前の事しかないてないぞ
・キャッシュは最小限にする(無駄な部分はGCで開放しておく)
・メモリリークは起こさない(同上)
・メモリアロケートを最小限にする(何度も呼ばれるデータはキャッシュしておく)
無条件にGCが悪だとはどこにも書いてない
ケースバイケースでGCを有効活用しようってことだろ
>>234-235あたりが的を射ている意見だと思うがな
これを読んで「GCを出来るだけ発生させないように」と結論するのは「木を見て森を見ず」だろ
いえ、GCが起きてるんだからそれにより
パフォーマンスは激落ちします。
だからオブジェクトを作ってはいけません。
すべて関数でやるべきです。
パフォーマンスは激落ちします。
だからオブジェクトを作ってはいけません。
すべて関数でやるべきです。
> ・メモリリークは起こさない(同上)
文脈をよめばわかるが、これはブラウザのバグによるメモリリークに限定されず、プログラマが意図せずリークさせる場合を含む
>>234のいうように関数言語的コードで起きやすい(jQuery, lodash信者辺りが好んで使うようだが)
スコープチェーンが分かってる人なら出来るだけ関数をネストさせないように気をつけるものだが、関数言語的コードでは延々と関数をネストさせるからな
文脈をよめばわかるが、これはブラウザのバグによるメモリリークに限定されず、プログラマが意図せずリークさせる場合を含む
>>234のいうように関数言語的コードで起きやすい(jQuery, lodash信者辺りが好んで使うようだが)
スコープチェーンが分かってる人なら出来るだけ関数をネストさせないように気をつけるものだが、関数言語的コードでは延々と関数をネストさせるからな
>>277
Gmailのメモリ肥大化問題をなぜ無視する？
↓を読んだら？
http://www.html5rocks.com/ja/tutorials/memory/effectivemanagement/#toc-call-to-action
----
1. あなたのアプリケーションはどのくらいメモリを使用しますか？
あなたのアプリケーションはメモリを使いすぎている可能性があります。
よく誤解されていることですが、多すぎるメモリはアプリケーションの全体のパフォーマンスに悪い影響を及ぼします。
正確な数値を知ることは難しいですが、過剰なページキャッシュがパフォーマンスに影響を及ぼしていないか検証してください。
2. あなたのページにリークはありませんか？
あなたのページでメモリリークが発生すると、あなたのページのパフォーマンスだけではなく、他のタブにも影響を及ぼす可能性があります。
Object Tracker を使ってリークの原因を特定してください。
----
Gmailのメモリ肥大化問題をなぜ無視する？
↓を読んだら？
http://www.html5rocks.com/ja/tutorials/memory/effectivemanagement/#toc-call-to-action
----
1. あなたのアプリケーションはどのくらいメモリを使用しますか？
あなたのアプリケーションはメモリを使いすぎている可能性があります。
よく誤解されていることですが、多すぎるメモリはアプリケーションの全体のパフォーマンスに悪い影響を及ぼします。
正確な数値を知ることは難しいですが、過剰なページキャッシュがパフォーマンスに影響を及ぼしていないか検証してください。
2. あなたのページにリークはありませんか？
あなたのページでメモリリークが発生すると、あなたのページのパフォーマンスだけではなく、他のタブにも影響を及ぼす可能性があります。
Object Tracker を使ってリークの原因を特定してください。
----
>>280
関数を入れ子にするならクロージャが発生するだろ
関数を入れ子にするならクロージャが発生するだろ
>>282
たとえばこれとかネイティブなJavaScriptですが、クロージャー発生しますよ。
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach
たとえばこれとかネイティブなJavaScriptですが、クロージャー発生しますよ。
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach
やっぱりクロージャーよりも、Javaのラムダの方がすぐれてるってわけね。
クロージャーだと循環参照が生まれやすいが、
ラムダは、関数の中から関数の外を参照できないから
循環参照は生まれにくい。
クロージャーは諸悪の根源である。
クロージャーだと循環参照が生まれやすいが、
ラムダは、関数の中から関数の外を参照できないから
循環参照は生まれにくい。
クロージャーは諸悪の根源である。
>>283
だから何？
だから何？
書き方の問題なんだからネイティブでも問題が発生するのは当然
関数言語的コードでそういう問題が起きやすいといわれているだけ
関数を使わない選択肢を取れないからね
関数言語的コードでそういう問題が起きやすいといわれているだけ
関数を使わない選択肢を取れないからね
ここではっきり言っておこう。
C言語は関数型言語である。
なぜならば、関数を使うからである。
C言語は関数型言語である。
なぜならば、関数を使うからである。
普通のJSではアクセスできないオブジェクトを使ってるっぽいから出来ないみたいだ
まぁ当たり前か。。
まぁ当たり前か。。
jQueryはメモリリークを起こす
なぜならクロージャーを使うからだ。
っていうのなら、クロージャーを使わないで
ボタンのクリックのイベントハンドラを書いてみたら？
なぜならクロージャーを使うからだ。
っていうのなら、クロージャーを使わないで
ボタンのクリックのイベントハンドラを書いてみたら？
var dom = document.getElementById('test');
function test(e){
dom.style.left = e.pageX+'px';
dom.style.top = e.pageY+'px';
};
document.addEventListener('mousemove',test);
jqueryを使わないこんな最小限のコードでも
ドラッグ時のカクつき現象起きるね
これはもうどうしようもないのか・・
function test(e){
dom.style.left = e.pageX+'px';
dom.style.top = e.pageY+'px';
};
document.addEventListener('mousemove',test);
jqueryを使わないこんな最小限のコードでも
ドラッグ時のカクつき現象起きるね
これはもうどうしようもないのか・・
今大変なことに気付いたぜ
「fireworksでベクタ図形を描いてドラッグしてクルクルずっと回していたらカクついた」
つまりブラウザ固有の問題ではないということ・・
催眠術だとか超スピードだとか
そんなチャチなもんじゃ断じてねえぜ
トラックパッドのドライバの問題なのか、なんなのかしらんけど・・
「fireworksでベクタ図形を描いてドラッグしてクルクルずっと回していたらカクついた」
つまりブラウザ固有の問題ではないということ・・
催眠術だとか超スピードだとか
そんなチャチなもんじゃ断じてねえぜ
トラックパッドのドライバの問題なのか、なんなのかしらんけど・・
>>62の件ですが、
普段はbootcampのwin7使っているのですが、
OSXにしたらカク付きませんでした・・。
まさか本当にカク付くのが自分だけとは思いもしませんでした
結果的にGCに詳しくなったという副産物はありましたが
かくつかないという書き込みをはなから信じずに暴言をはいたりしてしまい
すみませんでした
普段はbootcampのwin7使っているのですが、
OSXにしたらカク付きませんでした・・。
まさか本当にカク付くのが自分だけとは思いもしませんでした
結果的にGCに詳しくなったという副産物はありましたが
かくつかないという書き込みをはなから信じずに暴言をはいたりしてしまい
すみませんでした
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.128 + (1001) - [97%] - 2016/2/26 6:45
- + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.116 + (1002) - [97%] - 2014/7/1 0:45
- + JavaScript の質問用スレッド vol.115 + (1001) - [97%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.114 + (1001) - [97%] - 2014/5/3 10:45
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.108 + (1001) - [97%] - 2013/9/21 15:16
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.100 + (1001) - [95%] - 2012/6/13 22:46
- + JavaScript の質問用スレッド vol.125 + (1001) - [95%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.124 + (1001) - [95%] - 2015/7/16 1:30
トップメニューへ / →のくす牧場書庫について