アカウント名:
パスワード:
malloc/freeの処理コストってどれくらいかかるんだろう。メモリがバカ高かった時代はmalloc/freeで使用量を厳密に、というのはわかるんだが、ンGB当たり前の昨今、malloc/freeの処理コストの方が高くなったりしないのかな?と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。
・・・malloc/free叩いとらんな、最近。
>malloc/freeの処理コストの方が高くなったりしないのかな?>と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。
チマチマ何回かに分けて取るより一回にまとめて取った方が相対的に安くなるので、「だいたい、このくらい」でまとめて取ってから、それをアプリ内部でチマチマ切り刻んで使うというテクニックは昔からあったと思います。
そしてJVMなんかだと、それを自動でやってくれるので、Javaな人にとってはこれも「もうやらなくていい昔のコーディングテクニック」の一つですね。
それから、OSが仮想記憶をサポートして以降は、mallocは実メモリを確保するわけではなくOSの管理テーブルに予約するだけなので、ちょっとくらい大きい領域を予約しても影響はすごく小さくなってるはずです。
>そうか、Javaだと(よほど変なことをしない限り)メモリリーク心配しなくていいのか(本当?)
いえいえ、お馬鹿なコードを書くとリークしていきますよ。使わなくなったオブジェクトに対する参照をつかんだままにしてればいくらでもメモリ使用量は増えていきますから。
スコープを外れた変数のつかんでるオブジェクトの回収とかは勝手にやってくれますが変数参照が生き残っていれば回収できないのです。プログラムグローバルなキャッシュを何も考えずに書かせると、そんなコードができるんじゃないですかね。ただ、まぁ、そうはいってもCに比べれば格段に問題のあるコードは書きにくくなっているでしょうね。
>>そうか、Javaだと(よほど変なことをしない限り)メモリリーク心配しなくていいのか(本当?)>いえいえ、お馬鹿なコードを書くとリークしていきますよ。
「メモリリーク」という単語を、「ポインタ(或いは参照)を全て手放したにもかかわらず、領域の解放(free)を 忘れたために、メモリを少しずつ食い尽くしていく現象」と定義するなら、Javaだと「メモリリーク」の心配はほぼありません。#まさに「よほど変なことをしない限り」、且つ「VMやフレームワークにバグがない限り」。#C言語で長期間動作するアプリを作るのが難しいのは、このような「狭義の#メモリリーク」の検
結果を区別する必要は無いけど、原因を区別する必要は有るね。
区別する気が無い人なら運用者にもならないで欲しい。なぜならその人は、バグったときにその区別ができるような情報をデバッグ者に渡す「気」が無いわけでしょ?
そういうところで情報断絶をおこしてデバッグが立ち往生すること、実際凄く多いんだよorzつまりそういう場合にバグがいつまでたっても直らないのはハッキリいってそいつのせい。
全く気にする必要が無い人はそれはエンドユーザというんだよ。運用者じゃない。
運用者は開発者とともに原因と結果の界面に居る人だ(でないと困る)。両方に目配りをしてもらいたい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
時々思うんだが (スコア:3, 興味深い)
malloc/freeの処理コストってどれくらいかかるんだろう。メモリがバカ高かった時代はmalloc/freeで使用量を厳密に、というのはわかるんだが、ンGB当たり前の昨今、malloc/freeの処理コストの方が高くなったりしないのかな?と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。
・・・malloc/free叩いとらんな、最近。
-- gonta --
"May Macintosh be with you"
Re: (スコア:2, 興味深い)
>malloc/freeの処理コストの方が高くなったりしないのかな?
>と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。
チマチマ何回かに分けて取るより一回にまとめて取った方が相対的に安くなる
ので、「だいたい、このくらい」でまとめて取ってから、それをアプリ内部で
チマチマ切り刻んで使うというテクニックは昔からあったと思います。
そしてJVMなんかだと、それを自動でやってくれるので、Javaな人にとっては
これも「もうやらなくていい昔のコーディングテクニック」の一つですね。
それから、OSが仮想記憶をサポートして以降は、mallocは実メモリを確保する
わけではなくOSの管理テーブルに予約するだけなので、ちょっとくらい大きい
領域を予約しても影響はすごく小さくなってるはずです。
Re: (スコア:0)
そうか、Javaだと(よほど変なことをしない限り)メモリリーク心配しなくていいのか(本当?)でも起動時に1GByte以上のヒープサイズが必要ですとかいわれると、いくらメモリ安くなったとっていってもすこしひくなぁ。
Re: (スコア:1)
>そうか、Javaだと(よほど変なことをしない限り)メモリリーク心配しなくていいのか(本当?)
いえいえ、お馬鹿なコードを書くとリークしていきますよ。
使わなくなったオブジェクトに対する参照をつかんだままにしてれば
いくらでもメモリ使用量は増えていきますから。
スコープを外れた変数のつかんでるオブジェクトの回収とかは勝手にやってくれますが
変数参照が生き残っていれば回収できないのです。
プログラムグローバルなキャッシュを何も考えずに書かせると、そんなコードができるんじゃないですかね。
ただ、まぁ、そうはいってもCに比べれば格段に問題のあるコードは書きにくくなっているでしょうね。
Re: (スコア:2, 参考になる)
>>そうか、Javaだと(よほど変なことをしない限り)メモリリーク心配しなくていいのか(本当?)
>いえいえ、お馬鹿なコードを書くとリークしていきますよ。
「メモリリーク」という単語を、
「ポインタ(或いは参照)を全て手放したにもかかわらず、領域の解放(free)を
忘れたために、メモリを少しずつ食い尽くしていく現象」
と定義するなら、Javaだと「メモリリーク」の心配はほぼありません。
#まさに「よほど変なことをしない限り」、且つ「VMやフレームワークにバグがない限り」。
#C言語で長期間動作するアプリを作るのが難しいのは、このような「狭義の
#メモリリーク」の検
Re: (スコア:3, 参考になる)
言葉の定義がどうであろうと起きている現象がなんであろうと
問題ですね。
このメモリリークの広義/狭義(あるいはメモリリーク/メモリリテンション)って
のは良く聞く話なのだけど運用者にとっては区別する意味が全くない。
この話を聞いて私が思い出す言葉は「五十歩百歩」です。
Re:時々思うんだが (スコア:0)
結果を区別する必要は無いけど、
原因を区別する必要は有るね。
区別する気が無い人なら運用者にもならないで欲しい。
なぜならその人は、バグったときにその区別ができるような情報をデバッグ者に渡す「気」が無いわけでしょ?
そういうところで情報断絶をおこしてデバッグが立ち往生すること、実際凄く多いんだよorz
つまりそういう場合にバグがいつまでたっても直らないのはハッキリいってそいつのせい。
全く気にする必要が無い人はそれはエンドユーザというんだよ。運用者じゃない。
運用者は開発者とともに
原因と結果の界面に居る人だ(でないと困る)。両方に目配りをしてもらいたい。