How accurate is System.Diagnostics.Stopwatch? I am trying to do some metrics for different code paths and I need it to be exact. Should I be using stopwatch or is there another solution that is more accurate?
I have been told that sometimes stopwatch gives incorrect information.
Why don't you profile your code instead of focusing on microbenchmarks?
There are some good open source profilers, like:
I've just written an article that explains how a test setup must be done to get an high accuracy (better than 0.1 ms) out of the stopwatch. I think it should explain everything.
Performance Tests: Precise Run Time Measurements with System.Diagnostics.Stopwatch
The System.Diagnostics.Stopwatch class does accurately measure time elapsed, but the way that the ElapsedTicks method works has led some people to the conclusion that it is not accurate, when they really just have a logic error in their code.
The reason that some developers think that the Stopwatch is not accurate is that the ElapsedTicks from the Stopwatch DO NOT EQUATE to the Ticks in a DateTime. The problem arises when the application code uses the ElapsedTicks to create a new DateTime.
var watch = new Stopwatch();
watch.Start();
... (perform a set of operations)
watch.Stop();
var wrongDate = new DateTime(watch.ElapsedTicks); // This is the WRONG value.
If necessary, the stopwatch duration can be converted to a DateTime in the following way:
// This converts stopwatch ticks into DateTime ticks.
// First convert to TimeSpan, then convert to DateTime
var rightDate = new DateTime(watch.Elapsed.Ticks);
Here is an article that explains the problem in more detail: http://geekswithblogs.net/BlackRabbitCoder/archive/2012/01/12/c.net-little-pitfalls-stopwatch-ticks-are-not-timespan-ticks.aspx
Note that the content is no longer available at the original link. Here is a reference to the archived content from the Wayback Machine: https://web.archive.org/web/20190104073827/http://geekswithblogs.net:80/BlackRabbitCoder/archive/2012/01/12/c.net-little-pitfalls-stopwatch-ticks-are-not-timespan-ticks.aspx
MSDN has some examples of the stopwatch. They also have it showing how accurate it is within nanoseconds.
First, exact is of course not a possible or meaningful concept when talking about time or space, since no empyrical measurement of a physical magnitude can ever pretend to be exact.
Second, David Bolton's blog article may be useful. I'm quoting:
If this was timed with the high resolution counter then it will be accurate to microseconds. It is actually accurate to nanoseconds (10-9 seconds, ie a billionth of a second) but there is so much other stuff going on that nanosecond accuracy is really a bit pointless. When doing timing or benchmarking of code, you should do a number of runs and take the average time- because of other processes running under Windows, how much swapping to disk is occurring etc, the values between two runs may vary.
The Stopwatch class returns different values under different configurations as the frequency depends on the installed hardware and operating system.
Using the stopwatch class, we can have only the rough estimation of execution time. And for each execution, it returns a different value, so we have to take average of different execution.
More information: Stopwatch Class
In addition to seconding the advice of HUAGHAGUAH, I'd add that you should be very skeptical of microbenchmarks in general. While close-focused performance testing has a legitimate place, it's very easy to tweak an unimportant detail. So write and verify code that is designed for readability and clarity, then profile it to find out where the hot spots are (or whether there are any worth worrying about), and then tune (only) those portions.
I recall working with a programmer who micro-optimized a bit of code that executed while the system waited for human input. The time savings absolutely disappeared in the between-keystroke lag!
Why don't you profile your code instead of focusing on microbenchmarks?
There are some good open source profilers, like:
If you want more precise timings. Take a look at the QueryPerformanceCounter. MSDN link for QueryPerformanceCounter. A neat implementation is given here. The example loads coredll.dll for CE, for Windows you should load the Kernel32.dll as stated in the MSDN documentation.
I realize this is a very old thread, but it's still the first hit and I'd like to add a bit that led me here in the first place. If you:
Console.WriteLine(timer.Elapsed.Seconds.ToString())
... you will periodically get very odd results, like "6" when it actually took much longer. That's because the correct call is the rather non-obvious-at-first-glance:
Console.WriteLine(timer.Elapsed.TotalSeconds.ToString())
... which of course makes sense in retrospect.
© 2022 - 2025 — McMap. All rights reserved.