namazu-ml(ring)

[Rei FURUKAWA <furukawa@xxxxxxxxxxxxxxxx>]

古川です。

>> On Tue, 2 Mar 1999 16:16:55 +0900, takehi-s@xxxxxxxxxxx (SHIOZAKI Takehiko) said:
  >> メモリを喰いそうなところがあったので、ちょっと修正してみました。
  > 同じのを対象にして試してみましたが、やはりreading NMZ.iのところで終わっ
  > てしまいます。
  > ただ、たまたまかもしれませんが、今回は「out of swap space」まではゆかず
  > に「Out of memory!」ですんでます(?)。

それはよかった(?)。


  > 念のためにディレクトリの中身も載せておきます。

  > -rw-r-----  1 takehi-s  webusr   26955135 Mar  2 14:09 TMP_I.tmp.2282
  > -rw-r-----  1 takehi-s  webusr   26206208 Feb 26 22:10 TMP_I.tmp.718
  > -rw-r-----  1 takehi-s  webusr  110728525 Mar  2 13:39 TMP_O.tmp.2282
  > -rw-r-----  1 takehi-s  webusr  110728525 Feb 26 13:26 TMP_O.tmp.718

前回のは死ぬ (規模のデータに到達する) までに 9 時間近くかかっているの
に、今回は 30 分くらいですね。やはり、ちゃんと (un)pack を使うと、効果
がありますね。ってあたりまえか…


>> On Wed, 3 Mar 1999 10:55:50 +0900, takehi-s@xxxxxxxxxxx (SHIOZAKI Takehiko) said:
  > 実は私もこれは気になってます。
  > でも、プロセス自体がそこまで大きくなってほしくないという気もしてます。
  > やはりgcnmzにもチェックポイント機能が必要? と振っておきつつ、

mknmz は本当に大きなデータを扱っているからチェックポイントは必要ですが、
gcnmz は書き方がヘタなだけですから、きっと不要でしょう。


いつぞやの、「gcnmzが異様にメモリを喰うバグ」のときと同じパターンとす
ると、local が悪さをしているのでしょう (って、これもよく理解できていな
いのですが) 。特に for が暗黙のうちに local を使っている (?) あたりが
怪しいかなあ、と思い、ここいらへんを中心に見直してみました。

なんべんも申し訳ありませんが、試してみていただけますか？

    http://www01.tcp-ip.or.jp/~furukawa/namazu/gcnmz.pl.gz
    (サイズは 4113 バイトです)

これでダメなら…また出直します。


# メモリ周辺の話は、私も興味がある、かつ、よく分からないところなので、
# いろいろ教えてください。

-- 

                                        ヤマハ(株)ピアノプレーヤ設計課
                                                              古川 令
                                             furukawa@xxxxxxxxxxxxxxxx