パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

もうやらなくていい昔のコーディングテクニックあれこれ」記事へのコメント

  • malloc/freeの処理コストってどれくらいかかるんだろう。メモリがバカ高かった時代はmalloc/freeで使用量を厳密に、というのはわかるんだが、ンGB当たり前の昨今、malloc/freeの処理コストの方が高くなったりしないのかな?と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。

    ・・・malloc/free叩いとらんな、最近。

    --
    -- gonta --
    "May Macintosh be with you"
    • Re: (スコア:2, 興味深い)

      >malloc/freeの処理コストの方が高くなったりしないのかな?
      >と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。

      チマチマ何回かに分けて取るより一回にまとめて取った方が相対的に安くなる
      ので、「だいたい、このくらい」でまとめて取ってから、それをアプリ内部で
      チマチマ切り刻んで使うというテクニックは昔からあったと思います。

      そしてJVMなんかだと、それを自動でやってくれるので、Javaな人にとっては
      これも「もうやらなくていい昔のコーディングテクニック」の一つですね。

      それから、OSが仮想記憶をサポートして以降は、mallocは実メモリを確保する
      わけではなくOSの管理テーブルに予約するだけなので、ちょっとくらい大きい
      領域を予約しても影響はすごく小さくなってるはずです。

      • by Anonymous Coward
        特に、常駐プログラム(そう、デーモンとかサービスとか)だと、わずかなメモリリークでも、起動して一年後にシステム停止なんてことになって、深夜呼び出し&スッゴイ怒られる、ので、未だに、メモリ管理の仕組み自体は、できるだけ自前で作りたいという人は多いかと。
        そうか、Javaだと(よほど変なことをしない限り)メモリリーク心配しなくていいのか(本当?)でも起動時に1GByte以上のヒープサイズが必要ですとかいわれると、いくらメモリ安くなったとっていってもすこしひくなぁ。
        • >そうか、Javaだと(よほど変なことをしない限り)メモリリーク心配しなくていいのか(本当?)

          いえいえ、お馬鹿なコードを書くとリークしていきますよ。
          使わなくなったオブジェクトに対する参照をつかんだままにしてれば
          いくらでもメモリ使用量は増えていきますから。

          スコープを外れた変数のつかんでるオブジェクトの回収とかは勝手にやってくれますが
          変数参照が生き残っていれば回収できないのです。
          プログラムグローバルなキャッシュを何も考えずに書かせると、そんなコードができるんじゃないですかね。
          ただ、まぁ、そうはいってもCに比べれば格段に問題のあるコードは書きにくくなっているでしょうね。

          • Re: (スコア:2, 参考になる)

            >>そうか、Javaだと(よほど変なことをしない限り)メモリリーク心配しなくていいのか(本当?)
            >いえいえ、お馬鹿なコードを書くとリークしていきますよ。

            「メモリリーク」という単語を、
            「ポインタ(或いは参照)を全て手放したにもかかわらず、領域の解放(free)を
             忘れたために、メモリを少しずつ食い尽くしていく現象」
            と定義するなら、Javaだと「メモリリーク」の心配はほぼありません。
            #まさに「よほど変なことをしない限り」、且つ「VMやフレームワークにバグがない限り」。
            #C言語で長期間動作するアプリを作るのが難しいのは、このような「狭義の
            #メモリリーク」の検

            • Re: (スコア:3, 参考になる)

              長期運用するとメモリの消費量が増えてゆくように見えるなら
              言葉の定義がどうであろうと起きている現象がなんであろうと
              問題ですね。

              このメモリリークの広義/狭義(あるいはメモリリーク/メモリリテンション)って
              のは良く聞く話なのだけど運用者にとっては区別する意味が全くない。

              この話を聞いて私が思い出す言葉は「五十歩百歩」です。
              • >運用者にとっては区別する意味が全くない。
                >この話を聞いて私が思い出す言葉は「五十歩百歩」です。
                プログラミングが分かってない人の意見かな。

                運用者にとっては違わないかもしれないけど、開発者にとっては全然違いますよ。

                狭義のメモリリークはデバッグが凄く難しい。
                それに比べ広義のメモリリークは対応が遥かに容易。

                結果として、開発に同じだけのリソースを割り振った場合に、
                Cで作った場合は開発期間が長期化しメモリリークが多く不安定で、
                Javaで作った場合は短い開発期間でもメモリリークが少なく安定する、
                という違いとなって現れることが多い。

                もちろん無限の開発コストと無限の開発期間がつぎ込める場合はこの限りではありません。

              • Re: (スコア:0, フレームのもと)

                >>運用者にとっては区別する意味が全くない。
                >>この話を聞いて私が思い出す言葉は「五十歩百歩」です。
                >プログラミングが分かってない人の意見かな。

                >運用者にとっては違わないかもしれないけど、開発者にとっては全然違いますよ。

                >狭義のメモリリークはデバッグが凄く難しい。
                >それに比べ広義のメモリリークは対応が遥かに容易。

                狭義/広義と使い分けているが、ただ単にスキル不足な気がする。
                昔ならいざ知らず、統合開発環境が主流な現在においてはどちらも容易。
                (ブレークポイント張りまくれるでしょ。スタックの中身ですら見えるでしょ。)
                プログラミングが分かってない人の意見かな。<

              • by firewheel (31280) on 2009年05月04日 22時05分 (#1559236)

                >昔ならいざ知らず、統合開発環境が主流な現在においてはどちらも容易。
                >(ブレークポイント張りまくれるでしょ。スタックの中身ですら見えるでしょ。)

                ブレークポイントはどこで何が発生するか分かってないと張っても無駄です。

                (狭義の)メモリリークの難しい点は、それを発生させる条件を特定することや、
                或いはそもそもメモリリークの有無を知ることそのものなんですよ。どういう
                条件の時にメモリリークが発生するのかまで特定できていれば、その部分のバグに
                ついては8割方片付いたも同じです。

                ブレークポイントはその残りの2割のさらに一部を楽にできる程度の効果しかありません。
                #そもそも統合開発環境がある前からデバッガなんてありましたよ。
                #ブレークポイントをはったりもやってた。でも(狭義の)メモリリークは
                #最も面倒なバグの一つとして有名だったのです。

                >出来ない君集団にやらせるなら、何使わせても一緒じゃね!?
                この部分についてだけは同意。

                親コメント

Stay hungry, Stay foolish. -- Steven Paul Jobs

処理中...