7

このビットは最近私を刺しました。コードからnumpy配列とリストとのすべての比較を削除することで解決しました。しかし、なぜガベージ コレクターはそれを収集するのに失敗するのでしょうか?

これを実行して、メモリが消費されるのを確認します。

import numpy as np
r = np.random.rand(2)   
l = []
while True:
    r == l

64 ビット Ubuntu 10.04、virtualenv 1.7.2、Python 2.7.3、Numpy 1.6.2 で実行

4

2 に答える 2

5

誰かがこれにつまずいて不思議に思う場合に備えて...

@Dugalはい、これは現在のnumpyバージョン（2012年9月）でのメモリリークであり、いくつかの例外が発生したときに発生すると思います（これとこれを参照）。gc@BiRicoが「修正」したという呼び出しを追加するのはなぜ私には奇妙に思えますが、それは明らかに直後に行わなければならないのですか？おそらく、Pythonのガベージがトレースバックを収集する方法とは奇妙です。誰かが例外処理とガベージコレクションのCPython Internalsを知っているなら、私は興味があります。

回避策：これはリストに直接関係していませんが、たとえばほとんどのブロードキャスト例外（空のリストは配列のサイズに適合しないため、空の配列でも同じリークが発生します。内部には、表示されない例外が用意されていることに注意してください）。したがって、回避策として、最初に形状が正しいかどうかを確認する必要があります（多くの場合、それ以外の場合は心配しません。正しく設定すると、小さな文字列がリークします）。

修正済み：この問題はnumpy1.7で修正される予定です。

于 2012-09-19T14:10:25.267 に答える
0

申し訳ありませんが、これ以上完全な回答はできませんが、これはガベージ コレクションと関係があるようです。Redhat 5.8 で python 2.7.2、numpy 1.6.1 を使用して、この問題を再現できました。ただし、次のことを試したところ、メモリ使用量は正常に戻りました。

import gc
import numpy as np
r = np.random.rand(2)   
l = []
while True:
    r == l
    gc.collect()
于 2012-09-19T02:25:19.727 に答える