ストップウォッチのボンネットの下

はじめに

非常に多くの場合、開発者は（自分のコードだけでなく）自分のコードの実行時間を測定する必要があります。 プログラミングを始めたばかりのとき、これらの目的でDateTime構造を使用しました。 時間が経ち、 ストップウォッチクラスについて学び、積極的に使用し始めました。 同様の状況があなたにもあったと思います。 ストップウォッチがどのように機能するかを自問しなかったわけではありませんが、その時点で、DateTimeで十分だった時間よりも正確に費やした時間を測定できることがわかりました。 読者だけでなく、Stopwatchクラスが実際にどのように機能するかを自分自身で説明し、DateTimeを使用した場合と比べてその長所と短所を見つける時が来ました。

DateTimeを使用する

DateTime構造を使用してコードの実行時間を測定するのは非常に簡単です。

var before = DateTime.Now; SomeOperation(); var spendTime = DateTime.Now - before; 

プロパティDateTime.Now-ローカルの現在の日付と時刻を返します。 DateTime.Nowプロパティの代わりに、DateTime.UtcNowプロパティを使用できます。これは現在の日付と時刻を返しますが、ローカルタイムゾーンではなく、Utc時間、つまり世界協定時刻として表します。

 var before = DateTime.UtcNow; SomeOperation(); var spendTime = DateTime.UtcNow - before; 

DateTimeの構造に関するいくつかの言葉

おそらく、DateTime構造のすべてについて考えている人はほとんどいません。 DateTime構造体の値は、メジャーと呼ばれる100ナノ秒単位で測定され、正確な日付は、西暦0001年1月1日00:00以降に渡されたメジャーの数で表されます。

たとえば、数値628539264000000000は、1992年10月6日00:00:00を表します。

DateTime構造には、過去のメジャーの数を含む単一のフィールドが含まれます。

 private UInt64 dateData; 

.NET 2.0以降、このフィールドの最上位2ビットはDateTimeタイプを示します：指定なし-指定なし、Utc-調整時間、ローカル-ローカル時間、および残りの62ビット-ティック数。 Kindプロパティを使用して、これらの2ビットを簡単に要求できます。

DateTimeを使用するのは何が悪いですか？

DateTime.Nowプロパティを使用して時間間隔を測定することはお勧めできません。その理由は次のとおりです。


DateTime.Nowプロパティの計算はDateTime.UtcNowに基づいています。つまり、最初に調整された時間が計算され、次にタイムゾーンオフセットが適用されます。

そのため、DateTime.UtcNowプロパティを使用する方がより正確になります。これははるかに高速に計算されます。


DateTime.NowまたはDateTime.UtcNowの使用に関する問題は、それらの精度が修正されていることです。 上記のように

1ティック= 100ナノ秒= 0.1マイクロ秒= 0.0001ミリ秒= 0.0000001秒

したがって、長さが1小節の長さより短い時間間隔を測定することは、単に不可能です。 もちろん、必要になることはまずありませんが、これを知る必要があります。

ストップウォッチクラスの使用

Stopwatchクラスは.NET 2.0に登場し、それ以降は変更されていません。 費やされた時間を正確に測定するために使用できる一連の方法とツールを提供します。

StopwatchクラスのパブリックAPIは次のとおりです。

プロパティ

1. 経過-合計経過時間を返します。
2. ElapsedMilliseconds-合計経過時間をミリ秒で返します。
3. ElapsedTicks-合計経過時間をタイマーティックで返します。
4. IsRunning-ストップウォッチタイマーが実行中かどうかを示す値を返します。

方法

1. リセット-時間間隔の測定を停止し、経過時間をリセットします。
2. 再起動-時間間隔の測定を停止し、経過時間をリセットし、経過時間の測定を開始します。
3. 開始-インターバルの経過時間の測定を開始または継続します。
4. StartNew-ストップウォッチの新しいインスタンスを初期化し、経過時間プロパティをゼロに設定して、経過時間の測定を開始します。
5. 停止-インターバルの経過時間の測定を停止します。

フィールド

1. 頻度-タイマーの頻度を1秒あたりのメジャー数として返します。
2. IsHighResolution-タイマーが高解像度パフォーマンスカウンターに依存するかどうかを示します。

StopWatchクラスを使用してSomeOperationメソッドの実行時間を測定するコードは次のようになります。

 var sw = new Stopwatch(); sw.Start(); SomeOperation(); sw.Stop(); 

最初の2行は、より簡潔に記述できます。

 var sw = Stopwatch.StartNew(); SomeOperation(); sw.Stop(); 

ストップウォッチの実装

StopwatchクラスはHPET（高精度イベントタイマー）に基づいています。 このタイマーは、時間測定の問題に終止符を打つためにMicrosoftによって導入されました。 このタイマーの周波数（最低10 MHz）は、システムの動作中に変化しません。 システムごとに、Windows自体がこのタイマーを実装するデバイスを決定します。

Stopwatchクラスには次のフィールドが含まれます。

 private const long TicksPerMillisecond = 10000; private const long TicksPerSecond = TicksPerMillisecond * 1000; private bool isRunning; private long startTimeStamp; private long elapsed; private static readonly double tickFrequency; 

TicksPerMillisecond-DateTimeメジャーの数を1ミリ秒で決定します。
TicksPerSecond-1秒のDateTimeメジャーの数を決定します。

isRunning-現在のインスタンスが実行中かどうか（Startメソッドが呼び出されたかどうか）を決定します。
startTimeStamp-起動時のメジャーの数。
経過-費やされたメジャーの総数。

tickFrequency-ストップウォッチのメジャーをDateTimeに簡単に変換できます。

静的コンストラクターはHPETタイマーの存在をチェックし、存在しない場合、ストップウォッチの頻度はDateTimeの頻度に設定されます。


このクラスの主なシナリオを上に示しました：時間を測定する必要があるStartメソッドへの呼び出し、そしてStopメソッドへの呼び出し。

Startメソッドの実装は非常に簡単です-最初のメジャー数を記憶します：


既に測定中のインスタンスでStartメソッドを呼び出しても何も起こらないことに注意してください。

Stopメソッドは簡単です。


停止したインスタンスでStopメソッドを呼び出すことも失敗します。

どちらのメソッドもGetTimestamp（）呼び出しを使用します。これは、呼び出し時にメジャーの数を返します。


HPET（高精度イベントタイマー）では、ストップウォッチの測定値はDateTimeとは異なります。

次のコード

 Console.WriteLine(Stopwatch.GetTimestamp()); Console.WriteLine(DateTime.UtcNow.Ticks); 

私のコンピューターのディスプレイに

 5201678165559 635382513439102209 

ストップウォッチのティックを使用してDateTimeまたはTimeSpanを作成するのは間違っています。 記録

 var time = new TimeSpan(sw.ElaspedTicks); 

明らかな理由により、誤った結果につながります。

ストップウォッチではなくDateTimeメジャーを取得するには、ElapsedおよびElapsedMillisecondsプロパティを使用するか、手動で変換する必要があります。 StopwatchメジャーをDateTimeメジャーに変換するには、クラスで次のメソッドを使用します。


プロパティコードは予想どおりに見えます。

ストップウォッチの使用の何が悪いのですか？

MSDNでのこのクラスへの注意：マルチプロセッサコンピューターでは、どのプロセッサーがスレッドを実行しているかは関係ありません。 ただし、BIOSまたは抽象機器層（HAL）のエラーにより、異なるプロセッサで時間を計算した結果が異なる場合があります。

これを避けるために、Stopメソッドにはif（elapsed <0）条件があります。

HPETの不適切な操作のために著者が問題に遭遇した記事をたくさん見つけました。

HPETがない場合、ストップウォッチはDateTimeクロックを使用するため、DateTimeの明示的な使用に対する利点は失われます。 さらに、特にループで発生する場合は、Stopwatchが行うメソッド呼び出しとチェックに費やした時間を考慮する必要があります。

モノのストップウォッチ

HPETを操作するためにネイティブのWindows関数に依存する必要がないため、Stopwatchクラスがモノラルでどのように実装されるのか疑問に思っていました。

 public static readonly long Frequency = 10000000; public static readonly bool IsHighResolution = true; 

モノのストップウォッチは常にDateTimeクロックを使用するため、コードが読みやすい場合を除き、DateTimeの明示的な使用に勝る利点はありません。

Environment.TickCount

また、Environment.TickCountプロパティについても説明する必要があります。このプロパティは、システムが起動してから経過した時間（ミリ秒単位）を返します。

このプロパティの値はシステムタイマーから取得され、符号付き32ビット整数として保存されます。 したがって、システムが継続的に実行されている場合、TickCountプロパティの値は約24.9日間増加し、ゼロから始まり値Int32.MaxValueで終わります。その後、値Int32.MinValueにリセットされ、負の数になり、再び増加し始めます。次の24.9日間スクラッチします。

このプロパティの使用は、GetTickCount（）システム関数の呼び出しに対応します。これは、対応するカウンターの値を返すだけなので、非常に高速です。 ただし、コンピューターのリアルタイムクロックによって生成された割り込みはカウンターを増やすために使用されるため、その精度は低くなります（10ミリ秒）。

おわりに

Windowsオペレーティングシステムには、多くのタイマー（時間間隔を測定できる機能）が含まれています。 それらのいくつかは正確ですが、高速ではなく（timeGetTime）、他は高速ですが正確ではありません（GetTickCount、GetSystemTime）、そしてMicrosoftによると、3番目は高速で正確です。 後者には、HPETタイマーと、それを使用できるようにする機能（QueryPerformanceFrequency、QueryPerformanceCounter）が含まれます。

Stopwatchクラスは、実際にはHPETのマネージラッパーです。 このクラスを使用すると、利点（時間間隔のより正確な測定）と欠点（BIOSのエラー、HALが誤った結果につながる可能性があります）の両方があり、HPETがない場合、その利点は完全に失われます。

Stopwatchクラスを使用するかどうかはあなた次第です。 しかし、このクラスの長所は短所よりもまだ大きいように思えます。