.NET Stopwatch - performance penalty

C#.NetStopwatch

C# Problem Overview


> Possible Duplicates:
> Is DateTime.Now the best way to measure a function's performance?
> Stopwatch vs. using System.DateTime.Now for timing events

I have code which needs to run as fast as possible. To be able to log the execution time, I use the Stopwatch class. I suspect, Stopwatch may effect the performance in a bad way. Maybe using a DateTime difference may be more effective?

Which one do you think has better performance?

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# Solutions


Solution 1 - C#

The Stopwatch isn't doing anything between the calls to Start and Stop... It just stores the current timestamp (via QueryPerformanceCounter) when you start it, and compare it to the current timestamp when you stop it. So there is no reason it could affect the performance of your code, at least not significantly. Stopwatch was designed specifically for accurate time measurements, so you can be sure it is thoroughly optimized. It is also much more accurate than comparing successive values of DateTime.Now. ...

Solution 2 - C#

Since your profiling code gets executed only once, its performance impact should be negligible. It's only a problem if you put calls to stopwatch inside your inner loop/critical codepaths.

GetTickCount() should be one of the fastest ways to profile, but it only has an accuracy of a few milliseconds. The GetTickCount() Windows API function does only check a simple variable (which is updated every few milliseconds); its cost is the cost of a native method invocation and nothing more. It's exposed as Environment.TickCount in .NET. But as I said, I doubt this matters. DateTime.UtcNow/Now have the same (low) accuracy as GetTickCount.

In theory, there could be some effect on the jitter, but that's unlikely.

Solution 3 - C#

The answer really depends on what precision are you trying to achieve. For precision greater than seconds the stopwatch is a better approach due to using a more precise measurement system than the datetime. See http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.aspx

From the performance point of view, I doubt there is that much of a difference seeing how the Start() and DateTime.Now store the values from the corresponding measurement system and when retrieving the milliseconds it calculates the difference and converts (as required) to the corresponding measurement unit

Solution 4 - C#

I don't think that it is really matters if you are only calling it a few times, However, everything is dependent on what is the level of accuracy you are asking for; Stopwatch is much more accurate, because it relies on QueuePerformanceCounter API, so it uses a higher resolution.

Solution 5 - C#

I think the second one will be more efficient as far as performance is concerned, and as the links in the comment indicate, if you want to measure time below seconds then DateTime won't be accurate although it would be efficient

I think so because StopWatch would be measuring the ticks continuously as compared to DateTime which will only hold one instance of DateTime, that is, startTime.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionAhmet AltunView Question on Stackoverflow
Solution 1 - C#Thomas LevesqueView Answer on Stackoverflow
Solution 2 - C#CodesInChaosView Answer on Stackoverflow
Solution 3 - C#virlan2004View Answer on Stackoverflow
Solution 4 - C#Jalal SaidView Answer on Stackoverflow
Solution 5 - C#Haris HasanView Answer on Stackoverflow