NEMCHI 1.4.20をリリースしました。
バグ修正とメモリ消費の抑制対策を入れています。
プログラム的なところになりますが、今までウィンドウの移動やサイズ変更中に通知ウィンドウが消えてしまわないように、ウィンドウに何かしているときは、消えるまでのタイマーをリセットするようにしていました。
タイマーのリセットはタイマーを一旦停止して、再度開始することで行っています。
ただ、調べてみると、どうも.NETはタイマーを開始する時にメモリーを消費し、ストップするとガベージコレクションの対象になるだけで、次にタイマーを開始すると、またメモリーを消費することが分かりました。
つまり、ウィンドウを動かしている間にタイマーを開始、停止を繰り返すので、それだけでメモリをどんどん消費するようになっていました。
一応、あるところまで消費するとガベージコレクションが働きタイマーのメモリは破棄されるのですが、気を遣って定期的にマウスの座標を読み取り、通知ウィンドウ上にマウスがある場合にタイマーを停止し、ウィンドウから外れたときにタイマーを開始するようにしてみました。
MouseLeaveとかのイベントが使えるのでは?とプログラムやってる人は思われるかもしれませんが、これはポップアップ出したときにもイベントが発生してしまうので使えないんですよね。
いろいろ調べている時にガベージコレクションについて有用なページが見つかったので、紹介しておきます。
Microsoft .NET Framework の自動メモリ管理 Part I
ガベージコレクタは，メモリ内の型が表現しているリソースについての知識を持たないため，リソースの状態情報の破棄の実行方法を知ることができない。リソースを適切にクリーンアップするためには，プログラマの側でリソースを適切にクリーンアップする方法を知っているコードを書かなければならない。
はい、よくわかってませんでした、ガベージコレクション。
なかなかややこしいですが、よく読むとCとかやってない人でもイメージはつかめると思います。
しかし、Finalizeメソッドがあるとメモリ解放が遅れるなんて知りませんでした。
あと、GCが起きるのはGC 0のヒープが一杯になったタイミングなんですね。
いつ解放されるのかよくわからないガベージコレクションでしたが、少しはっきりしてきました。
あとパフォーマンスモニターを使った監視も為になりました。
これ使ってNEMCHI動かすと、確かに特定のタイミングでGCが作動しているのがわかります。
ただ、タスクマネージャで見ても使用メモリがなかなか減らないのはなぜなんだろう?
あと、弱い参照も場合によっては使えるかもしれませんね。
NEMCHIはそんなにでかいデータ扱わないので、あまり関係ありませんが。
たぶん、.NET2.0だともっと賢く動いてくれるんだろうな。
