技術(.NET 1.1)

[.NET]DataSet内の検索とパフォーマンス

Kazuaki Shigetou — Tue, 20 Nov 2007 15:05:00 GMT

DataSetの検索には以下を考慮する。

主キーを条件に検索する場合はDataTableのRowsプロパティのFindメソッドを使う。
Selectメソッドはインデックスを利用しないので極力使わない。
同じフィールドに対しての検索を繰り返す場合はDataViewを生成して（インデックスを生成して）FindまたはFindRowsメソッドを利用する。ただし、試行回数が少ない場合はインデックス生成のコストのほうが高くつくため、DataTableのSelectメソッドを利用する。

[.NET]DateTime.Nowの精度についてメモ

Kazuaki Shigetou — Tue, 20 Nov 2007 14:49:00 GMT

.NET で現在の日付と時刻を取得するにはDateTime構造体（System名前空間）のオブジェクトのNowプロパティを呼び出す。
ただ少し注意が必要なのは、このDateTime.Nowの精度は10ms前後らしく、10ms前後に一度DateTime.Nowの返す値が変わる

だから以下のような処理をしたら、

static void Main(string[] args)
{
      Console.WriteLine("start {0:yyyy/MM/dd HH:mm:ss.ffffff}", DateTime.Now);//①

      Console.WriteLine(" なんか処理したよ");

      Console.WriteLine("end   {0:yyyy/MM/dd HH:mm:ss.ffffff}", DateTime.Now);//②
}

①～②間が0から10ms前後の場合だと同じ値が出力されることがあるわけで・・・。（マシンスペックや処理内容による）

start 2007/11/20 14:33:05.510467
なんか処理したよ
end 2007/11/20 14:33:05.510467

経過時間を正確に取りたい場合はSystem.Diagnostics.Stopwatch クラス（.NET Fx2.0の場合）を使うようにする。
また、前回実行日時と今回実行日時を比較する場合なんかにDateTime.Nowで取得した値を使うのはNGなんだなぁ。

メモリリーク

Kazuaki Shigetou — Sun, 03 Dec 2006 07:45:00 GMT

「メモリリークだよ・・・」ということでヘルプに入りました。一応解決したのでメモメモ。

　当該アプリは.NET Fx1.1、MTAのコンソールアプリケーション。メインスレッドが処理スレッド（System.Thread.Threading）をいくつか起動して、メインスレッド自体がスピンロックでポーリングして処理スレッドが終了するまで待機するというつくり。

　症状を整理すると以下のとおり。

プロセス終了までメモリ使用量が増加し続ける
特にGen 2のヒープメモリ使用量が右肩上がりに増える
Gen 1とGen 0のヒープメモリは定期的に開放されているっぽい
Gen 1とGen 0のGCは定期的に行われている
Gen 2のGCが殆ど行われない（Gen0,Gen1に比べて少ないのは当然だが、異常に少なすぎる）
シングルスレッドで処理した場合はメモリの増加は一定量を超えずGen 2のヒープも定期的に開放される

　とりあえずソースコードを眺めた。構造はマルチスレッドのデザインパターンを適用した、シンプルでそれなりに考えられたものになっている。気になる点は下記3点。

スピンロックに再帰処理を利用している
非同期デリゲートで起こしたスレッドで長時間処理を行う実装になっている
BeginInvokeに対してEndInvokeを呼び出していない

　んー、スピンロックを再帰処理で実現したらコールスタックには積まれる一方じゃないか・・・。

　気になる点を一つずつ修正して検証をしてみたけど、症状は改善せず・・・。色々試しているうちにスピンロックの待機方法を変更してみた（Thread.Sleep→WaitHandle.WaitOne）。すると症状は嘘のように治り、リークが発生しなくなった。パフォーマンスモニタで計測してみるとGen 2 GCが理想的に行われるようになっていた。とりあえず問題は解決、Thread.SleepをWaitHandleを利用した待機に変更しただけなんだが・・・。

　解決はしたものの、いまいち理屈が理解できていない。とりあえずThread.SleepがGCに何らかの影響を及ぼし、WaitHandle.WaitOneだと問題がないらしい（理屈は？？？）。※ちなみにThread.SpinWaitでも結果はThread.Sleepと同じ。

　Microsoftが提供しているCLRのメモリ管理とGCの仕組みについてのドキュメントを再読したが、いまいち納得がいかず。おそらくGCのスレッドハイジャックの仕組みに何か悪影響を与えていたんだろうなぁ。まだまだ勉強の余地がありだ。三流エンジニアは日々これ精進っす

[今回の教訓]

　スピンロックでポーリングの仕組みをとる際は、Thread.SleepではなくWaitHandle.WaitXXXを利用する。そうしないとGCが正しく働かずメモリが開放されないかも・・・

[参考]

ガベージコレクション入門: Microsoft .NET Framework の自動メモリ管理 Part II【http://www.microsoft.com/japan/msdn/net/mag00/GCI2.aspx】