.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;

I highly suspect use either will yield you the same results. Inconsequential differences. — Only Bolivian Here, Aug 08 '11 at 17:38
See http://stackoverflow.com/questions/2923283/stopwatch-vs-using-system-datetime-now-for-timing-events — ccellar, Aug 08 '11 at 17:38
See: http://stackoverflow.com/questions/28637/is-datetime-now-the-best-way-to-measure-a-functions-performance - tl;dr: Use the stopwatch. — Only Bolivian Here, Aug 08 '11 at 17:39
`DateTime` is likely to be very inaccurate if you are trying to measure performance with the kind of precision you desire. So for you; if you results are what is important, then you can rule `DateTime` out. — vcsjones, Aug 08 '11 at 17:40
I do not understand how this is exact duplicate. I suspect its reputation collection drive to mark the question duplicate and close them. — Rohit, Aug 18 '12 at 13:20
This is NOT a duplicate of the other questions indicated. This question is about the overhead of the call. The other questions are only about the accuracy of the returned information. — Neville Cook, Mar 30 '15 at 12:48
See ["Sidebar: Stopwatch is more efficient than DateTime.Now math"](http://geekswithblogs.net/BlackRabbitCoder/archive/2012/01/12/c.net-little-pitfalls-stopwatch-ticks-are-not-timespan-ticks.aspx). — user2864740, Nov 23 '15 at 17:23
The question https://stackoverflow.com/questions/9925598/c-sharp-performance-penalty-from-adding-stop-watch addresses the performance penalty of Stopwatch itself (it is pretty low) but doesn't compare it with DateTime. — Christopher Hamkins, Dec 17 '21 at 08:40

score 95 · Accepted Answer · answered Aug 08 '11 at 17:49

95

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. ...

answered Aug 08 '11 at 17:49

Thomas Levesque

286,951
70
623
758

10

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) – mistika Jun 16 '17 at 14:57
The explanation I was looking for. – Neo Dec 09 '17 at 08:41

score 10 · Answer 2 · edited Mar 22 '13 at 20:43

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.

score 3 · Answer 3 · answered Aug 08 '11 at 17:50

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

score 2 · Answer 4 · edited Mar 22 '13 at 20:45

2

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.

edited Mar 22 '13 at 20:45

Peter Mortensen

30,738
21
105
131

answered Aug 08 '11 at 17:42

Jalal Said

15,906
7
45
68

score 1 · Answer 5 · edited Mar 22 '13 at 20:44

1

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.

edited Mar 22 '13 at 20:44

Peter Mortensen

30,738
21
105
131

answered Aug 08 '11 at 17:39

Haris Hasan

29,856
10
92
122

+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. – nawfal Apr 22 '13 at 12:01

.NET Stopwatch - performance penalty

5 Answers5

Linked

Related