web-dev-qa-db-ja.com

.NETストップウォッチ-パフォーマンスの低下

可能な重複：
DateTime.Nowは関数のパフォーマンスを測定する最良の方法ですか？
ストップウォッチとタイミングイベントにSystem.DateTime.Nowを使用

可能な限り高速に実行する必要があるコードがあります。実行時間を記録できるようにするには、 Stopwatch クラスを使用します。ストップウォッチはパフォーマンスに悪い影響を与える可能性があります。おそらく、DateTimeの差を使用する方が効果的でしょうか？

どちらがパフォーマンスが良いと思いますか？

Stopwatch sw = new Stopwatch();
sw.Start();
int a = 5;

// Critical lines of code

long elapsedMs = se.Elapsed.TotalMilliseconds;

OR

DateTime startDate = DateTime.Now;
int a = 5;

// Critical lines of code

long elapsedMs = DateTime.Now.Subtract(startDate).TotalMilleseconds;
c#.netstopwatch
46
Ahmet Altun

Stopwatchは、StartとStopの呼び出しの間で何もしていません...開始時に（QueryPerformanceCounterを介して）現在のタイムスタンプを保存するだけです。停止し、現在のタイムスタンプと比較します。したがって、コードのパフォーマンスに影響を与える可能性がある理由はありませんが、少なくとも大きな影響はありません。 Stopwatchは正確な時間測定のために特別に設計されているため、完全に最適化されていることを確認できます。また、DateTime.Nowの連続した値を比較するよりもはるかに正確です。 ...

68
Thomas Levesque

プロファイリングコードは1回しか実行されないため、パフォーマンスへの影響はごくわずかです。内側のループ/クリティカルコードパス内でストップウォッチの呼び出しを行う場合にのみ問題になります。

GetTickCount()は、プロファイルを作成する最も速い方法の1つですが、数ミリ秒の精度しかありません。 GetTickCount() Windows API関数は、単純な変数（数ミリ秒ごとに更新される）のみをチェックします。そのコストはネイティブメソッド呼び出しのコストであり、それ以上のものはありません。 。NET でEnvironment.TickCountとして公開されます。しかし、私が言ったように、私はこの問題を疑います。 DateTime.UtcNow/Nowは、GetTickCountと同じ（低い）精度です。

理論的には、ジッターに何らかの影響がある可能性がありますが、それはありそうにありません。

9
CodesInChaos

答えは本当にあなたが達成しようとしている精度に依存します。秒よりも高い精度の場合、日時よりも正確な測定システムを使用するため、ストップウォッチはより良いアプローチです。 http://msdn.Microsoft.com/en-us/library/system.diagnostics.stopwatch.aspx を参照してください

パフォーマンスの観点から、Start（）とDateTime.Nowが対応する測定システムからの値を保存する方法と、ミリ秒を取得するときに差を計算し、（必要に応じて）対応する測定単位

2
virlan2004

あなたがそれを数回呼び出すだけなら本当に重要だとは思いませんが、すべてはあなたが求めている精度のレベル;に依存していますStopwatchはQueuePerformanceCounter AP​​Iに依存しているため、はるかに正確です。したがって、より高い解像度を使用します。

2
Jalal Said

パフォーマンスに関する限り、2番目の方が効率的だと思います。また、コメント内のリンクが示すように、秒未満の時間を測定する場合、DateTimeは正確ですが、正確ではありません

なぜなら、DateTimeの1つのインスタンス、つまりstartTimeのみを保持するDateTimeと比較して、StopWatchはティックを連続的に測定するからです。

1
Haris Hasan