.NET Stopwatch - performance penalty [duplicate]

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

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.

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

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.