1

メモリの断片化の問題だと思います。

最近、WinForms アプリケーションを WPF アプリケーションに移植しました。このアプリケーションが行ういくつかの画像処理があり、この処理はアプリの WinForms バージョンで常に機能していました。WPF に移動すると、処理が終了します。ライブラリへのデバッグはランダムな場所で停止しますが、常に null の配列、つまり割り当てに失敗します。

処理自体は ap/invoke によって呼び出される C++ ライブラリで行われ、かなりメモリを消費します。指定された画像が N x M ピクセルの大きさの場合、画像は N x M x 2 バイトの大きさになります (各ピクセルは unsigned short で、グレースケール画像です)。処理中、float 空間にある画像ピラミッドが作成されるため、合計メモリ使用量は N x M x (2 + 2 + 4 + 4 + 4 + 4) になります。ここで、最初の 2 は入力、2 番目は2 は出力、最初の 4 は float の入力、2 番目の 4 は 0 番目のレベル差画像、最後の 2 つの 4 はピラミッドの残りの部分です (これらはピラミッドであり、各レベルはそれぞれのサイズの半分であるため)方向、これらの 4 は上限です)。したがって、5000x6000 の画像の場合、600 MB であり、メモリに問題なく収まるはずです。

(マーシャリングを使用すると、メモリ要件がさらに N x M x 4 増加する可能性があります。つまり、C# 側の入力イメージと出力イメージ、および同じ配列が C++ 側にコピーされます。マーシャリング要件はさらに大きくなる可能性があります。 )

WinFormsと比較してWPFはどの程度断片化されていますか? この処理を実行する前にメモリを統合する方法はありますか? 破損が発生したときのランダムな性質のために断片化が問題であり、それは常にメモリ割り当ての問題であると思われます。

または、ソケットなどを介したデータ転送を使用して、処理を別のプロセスとして実行することにより、この問題を完全に回避する必要がありますか?

4

4 に答える 4

0

一般的に、メモリ管理についてもっと注意したいようです。つまり、メモリを注意深く管理する別のアドレススペースで処理エンジンを実行するか、メモリが断片化しすぎてその領域の画像のみを管理する前に、十分に大きなチャンクを事前に割り当てます。長時間実行されるプロセスでアドレス空間を.NETランタイムと共有していて、大きな連続した領域が必要な場合、ある時点で常に失敗する可能性があります。ちょうど私の2c。

于 2009-05-15T04:42:30.617 に答える
0

この投稿は役立つかもしれません http://blogs.msdn.com/tess/archive/2009/02/03/net-memory-leak-to-dispose-or-not-to-dispose-that-s-the-1 -gb-question.aspx

于 2010-01-14T06:34:56.343 に答える