のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,896人
頁
昨日: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で

    102 = :

    GCのタイミングは必ずしも定期的に行われる物では無く、実装による
    よってGCのせいにするのは馬鹿

    103 = :

    >>98
    そうですか
    ありがとうございました

    105 = :

    あほかこいつw
    俺がマシンを変えてもユーザーのマシンは変わらねーんだよ
    何の解決にもなってない

    106 = :

    どうせお前しか使ってないだろ

    108 = :

    type属性はもうつける意味が無いものになったよ。

    111 = :

    http://www.html5rocks.com/ja/tutorials/memory/effectivemanagement/

    新世代のガベージコレクションの実行時間は、10 ミリ秒のオーダーです。
    直感的に理解できると思いますが、アプリケーションがメモリアロケートを繰り返すと、
    いずれ 領域が枯渇してGCが発生します。特にゲーム開発者は注意してください。
    (60 fps を実現するために) 16ミリ秒のフレーム時間を保証するには、
    あなたのアプリケーションは一回たりともメモリをアロケートすることはできません。
    なぜなら、一回の新世代ガベージコレクションでフレーム時間のほとんどを使ってしまうからです。

    旧領域のメモリ領域でガベージコレクションが実行されると、
    必ず新世代のGCも実行されます。
    ひとたび処理が走ると、アプリケーションは秒のオーダーで実行が止まります。

    －－
    速い方のGCですら10msオーダー
    遅い方は1sオーダー
    レスポンシビリティが重要なアプリではGCに気を遣うのは当然のようですね

    113 = :

    今まで処理の重さとして感じていたことの多くがGCだったんじゃないかと思えてきた
    ほとんどの処理に比べてGCはでかすぎる。
    10msオーダーの処理なんて滅多にないし。
    となると速度的なベンチマークではなく
    メモリアロケーションを基準にコードを決めなくてはいけなくてはいけないのではないだろうか
    関数呼び出しはパフォーマンスが悪いと言われるが、
    アロケーション基準ではどうか？
    ローカル変数を使うよりも関数を呼び出す方がいいこともあるのではないでしょうか

    115 = :

    >>113
    その通りだ
    JSのゲームエンジンは如何にループ内でnewの類いをしないかが大事

    117 = :

    >>116
    勿論ロード中とかはnewするがループ中はなるべくすべきじゃない
    ちなみにネイティブアプリは自分で解放をコントロール出来るから普通にnewもしてるだろう
    それでも限界までメモリを使う場合は問題になることもあるだろうが

    118 = :

    jQueryのプラグイン使ってドヤ顔してJavaScript使えた気になってるのも嫌なんで、
    jQueryのプラグインでよさげなやつを車輪の再発明でエミュレートしたろうと思ってます。
    よろしくお願いします。

    119 = :

    おう、こちらこそよろしく～

    124 = :

    何度も使うarray.lengthをローカル変数に代入するというよくある高速化テクニックも
    メモリアロケートの観点からは、
    体感できないほどのコストのために余計なローカル変数を作ってゴミを増やしている
    と言えるかもしれませんね？

    125 = :

    >>123
    jQueryでもオブジェクトを生成する必要はないですけど

    127 = :

    数値型すらオブジェクトなんだから何やったってオブジェクト生成されることになるんじゃないのか

    128 = :

    オブジェクトはでかくて重い

    129 = :

    オブジェクトの参照も使い終わるとガベージになるのでしょうか？
    容量はかなり小さそうですが

    131 = :

    >>112
    lodashを使えばなんとかなるが現状その方法しかない

    132 = :

    は？意味はありますが？アホ？

    135 = :

    ガベージを増やさないためにはいかにオブジェクトを生成しないかが鍵になる
    >>109を参照せよ

    136 = :

    まず、ガベージコレクションが増えても
    パフォーマンスに影響がないんだ。

    反論は、何％と具体的にいうこと。
    できなければ、深夜に裸で町を猛ダッシュすること。

    138 = :

    引数に関数を渡す関数言語的な方法って
    ローカル変数が生成されては廃棄されていくから
    ガベージがものすごい速度で溜まっていくのでは？

    139 = :

    >>136
    まだそんなこと言ってんのかw
    >>111を参照せよ

    140 = :

    具体的な数値がでてるのが反論だとすると
    反論はまだ出てないな。
    もう5分も待ったのに。

    141 = :

    もしくは、裸で街を猛ダッシュした証拠でもいいんだが。
    約束はちゃんと守ろう。

    142 = :

    具体的な数値が>>111に書いてあるので参照せよ

    143 = :

    >>142
    あんた何を作ろうとしているの？
    60fpsを出す必要があるゲーム以外には全く関係ないって
    言ってるようにしか見えないんだが？

    もしくは、裸で街を猛ダッシュしてもよい。

    145 = :

    現在のCPUは速いので相当複雑な処理をさせても10msもかからない
    しかしGCは10msオーダー、1sオーダーという爆弾を平気で落として行くのだ
    JavaScriptプログラマーに必要なのは爪に火を灯すような高速化ではなく、
    なるべく爆弾が落ちないようにすること
    そいつはすべてを吹っ飛ばしていくほど強力なのだ

    147 = :

    ガベージコレクションが起きて10msも処理に
    時間がかかるのは1時間に1回ぐらいだよ。

    149 = :

    16msも遅延したらどうなるかわかってるの！

    その16msで生死が決まるんだよ。

    1フレームのレベルで戦っているんだからな。


    たとえ1フレームが1じかんに

    馬鹿のフリして核の秋田ｗ

    150 = :

    「今だったら」って>>111はgoogle I/O 2013なんだがw
    妄想を語り出すやつなんなんだろうな
    C級プログラマーの思考回路は理解できんわ


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

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

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