のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,645,174人
頁
昨日:no data人
頁
今日:人
頁
最近の注目
人気の最安値情報

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

JavaScript覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

251 = :

>>249
その場合もスコープから抜けるのがGCのトリガーであってオブジェクト生成がトリガーになってないだろう
そして、オブジェクトに限らず、プリミティブ値でも同様の問題は起きる
>>250
ボトルネックとなる部分から手を入れるのは当然の事だろう
例えば、>>230でGCよりもjQueryを止める方が効果的な事がわかる

252 = :

jqueryもキャッシュすればほとんど問題ないよ
オブジェクトを使い捨てにするのがまずい

253 = :

jqueryには端末間の差違を吸収するという役割があるんだから
使うのをやめるという発想はナンセンス
オブジェクトをキャッシュするだけで全然変わるんだから単にそうすればいいだけ

254 = :

>>252-253
では、問題ないと分かる比較コードを上げてみて

255 = :

>>154
出来ました
ありがとうございます

257 = :

>>254
何のためにだよw
比較コードってのはどうなるか分からないことを確かめるために書くんだよ
分かりきってるんだから意味ねーわ

258 = :

オブジェクトを作った時に遅くなるのは
オブジェクトを作るコストであって、
GCは関係ないだろｗ

259 = :

>>253
> jqueryには端末間の差違を吸収するという役割があるんだから
そんなのjQueryの役割のうち
ごく小さい部分でしか無いよ。

jQueryの凄さは要素をリストに置き換えて
リスト処理できるようにしたところにある。

263 = :

>>262
アホか。オブジェクトを作成する前に、
開始時刻を記録しないと意味ねーだろ

264 = :

>>262
GCが起きるタイミングはコントロールできないので
そのテストには意味がない

265 = :

>>263
ん？ やってもいいけど、オブジェクトを作成するのは
どちらも同じなんだから関係ないのでは？

遅い遅い、GCのせいだ！っていうけどさ、
それオブジェクトを作成する時間じゃねーの？

266 = :

>>264
少なくとも一回は起きてるだろ？
何言ってるんだ？

267 = :

たった一回GCが起きたからって違いなんて
計測できるわけじゃないんｗ

268 = :

だよなぁ。GCのコストなんてごく僅かなのに
何を気にしてるんだろう？

それよりももっと気にするべき所があるだろ。

269 = :

・インターバルで関数を呼び出し続ける
・その関数は内部で巨大なオブジェクトを作る
・一方は作成後破棄し、一方は保持し続ける

この二つを比較したらGCによる遅延を確認できるんじゃね
というか、googleのS級技術者が速くても10msオーダー、
遅い時には1sオーダー処理が停止するって言ってんのに
何を根拠にそれに疑問を持つんだ？？
俺の体感でもそのくらいだなって思うし、
D級プログラマーの疑問のポイントが理解できんわ

270 = :

>>260
>>230を見てからものをいえ

271 = :

いや書いてることがもうD級まるだしなんで、見るまでもないです

272 = :

>>257
おまえの自説の正しさを証明するために決まってるだろ
無根拠にjQueryは問題ないといわれても信用できんわ
わかりきった話で言えば、jQueryの方がコストが高いことはわかりきってるんだからテストする必要はないがな

273 = :

google I/Oのレポートを読んで、
B級以上のプログラマーは
「GCをなるべく起こさないコードを書くにはどうしたらいいのか」
っていう生産的な議論を始めるものだが
C級以下のプログラマーは
「GCなんてたいしたことない！そもそも起こらない！1％！」
とか言い出すから本当にどうしようもない

274 = :

>>271
おまえがD級だよ
jQueryのコストがGCよりも低いという明確な根拠を出せ

275 = :

まだやってんの？ｗ
俺が最初にネタでGCいいだしたんだけど
一体何時間無駄な時間費やしてるの？

276 = :

http://www.html5rocks.com/ja/tutorials/memory/effectivemanagement/
読んだが、当たり前の事しかないてないぞ
・キャッシュは最小限にする(無駄な部分はGCで開放しておく)
・メモリリークは起こさない(同上)
・メモリアロケートを最小限にする(何度も呼ばれるデータはキャッシュしておく)

無条件にGCが悪だとはどこにも書いてない
ケースバイケースでGCを有効活用しようってことだろ
>>234-235あたりが的を射ている意見だと思うがな
これを読んで「GCを出来るだけ発生させないように」と結論するのは「木を見て森を見ず」だろ

277 = :

いえ、GCが起きてるんだからそれにより
パフォーマンスは激落ちします。

だからオブジェクトを作ってはいけません。
すべて関数でやるべきです。

279 = :

> ・メモリリークは起こさない(同上)
文脈をよめばわかるが、これはブラウザのバグによるメモリリークに限定されず、プログラマが意図せずリークさせる場合を含む
>>234のいうように関数言語的コードで起きやすい(jQuery, lodash信者辺りが好んで使うようだが)
スコープチェーンが分かってる人なら出来るだけ関数をネストさせないように気をつけるものだが、関数言語的コードでは延々と関数をネストさせるからな

282 = :

>>280
関数を入れ子にするならクロージャが発生するだろ

283 = :

>>282
たとえばこれとかネイティブなJavaScriptですが、クロージャー発生しますよ。
http://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach

284 = :

やっぱりクロージャーよりも、Javaのラムダの方がすぐれてるってわけね。
クロージャーだと循環参照が生まれやすいが、
ラムダは、関数の中から関数の外を参照できないから
循環参照は生まれにくい。
クロージャーは諸悪の根源である。

285 = :

>>283
だから何？

286 = :

書き方の問題なんだからネイティブでも問題が発生するのは当然
関数言語的コードでそういう問題が起きやすいといわれているだけ
関数を使わない選択肢を取れないからね

287 = :

ここではっきり言っておこう。

C言語は関数型言語である。
なぜならば、関数を使うからである。

291 = :

普通のJSではアクセスできないオブジェクトを使ってるっぽいから出来ないみたいだ
まぁ当たり前か。。

292 = :

jQueryはメモリリークを起こす
なぜならクロージャーを使うからだ。

っていうのなら、クロージャーを使わないで
ボタンのクリックのイベントハンドラを書いてみたら？

295 = :

今大変なことに気付いたぜ
「fireworksでベクタ図形を描いてドラッグしてクルクルずっと回していたらカクついた」
つまりブラウザ固有の問題ではないということ・・
催眠術だとか超スピードだとか
そんなチャチなもんじゃ断じてねえぜ
トラックパッドのドライバの問題なのか、なんなのかしらんけど・・

298 = :

>>62の件ですが、
普段は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一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド

トップメニューへ / →のくす牧場書庫について