.NET Stopwatch - performance penalty

Question

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;

Solution 1

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

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

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

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

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.

View more solutions

Comments

[nawfal]

+1 for the first sentence which is correct. Getting current DateTime is just about reading a counter from memory. However, as you say, performance is not the right metric to think about here, its accuracy.

[mistika]

The question is also about what does the Stopwatch do inside Start() and Stop() calls and how this affects the application. VS2013 Performance Analyzer shows that the Stopwatch.Stop() wastes about 0.92% (app does 80000 sql queries, 1thread, sw.Start() / sw.Stop() before each)

[Neo]

The explanation I was looking for.