Introduction

If you are done measuring, yes, you should usually stop the Stopwatch. It is not always strictly required if the stopwatch object is about to go out of scope, but calling Stop() makes the measurement boundary explicit and prevents accidental extra timing.

What Stopwatch Actually Does

In .NET, Stopwatch measures elapsed time between Start and Stop. The Elapsed properties continue to reflect the running duration until the watch is stopped or reset.

That means this works:

1using System;
2using System.Diagnostics;
3
4class Program
5{
6    static void Main()
7    {
8        var sw = Stopwatch.StartNew();
9        DoWork();
10        sw.Stop();
11        Console.WriteLine(sw.ElapsedMilliseconds);
12    }
13
14    static void DoWork()
15    {
16        System.Threading.Thread.Sleep(100);
17    }
18}

The important part is not performance overhead. It is clarity. The call to Stop() marks the exact end of the measurement.

Is Stop() Strictly Necessary?

If the stopwatch is a local variable and you read Elapsed immediately at the end of the method, omitting Stop() can still produce the measurement you expect.

var sw = Stopwatch.StartNew();
DoWork();
Console.WriteLine(sw.ElapsedMilliseconds);

This often works because almost no time passes between the last line of work and the read of ElapsedMilliseconds.

However, the stopwatch is still running during that read, and during any later code that might accidentally reuse it.

So while omitting Stop() is sometimes harmless, it is usually less precise and less self-documenting.

Why Explicit Stop Is Better

Calling Stop() gives you three benefits:

• it freezes the intended measurement window
• it makes the code easier to read
• it avoids accidental extra elapsed time if more code is added later

That last point matters in maintenance. A method that once ended immediately after the measurement may later gain logging, cleanup, or other statements. If the stopwatch is still running, those lines quietly become part of the measured duration.

Use try and finally for Robust Timing

If the code under measurement can throw, stop the watch in a finally block.

1var sw = Stopwatch.StartNew();
2try
3{
4    DoWork();
5}
6finally
7{
8    sw.Stop();
9    Console.WriteLine(sw.ElapsedMilliseconds);
10}

This ensures the measurement still ends cleanly even when the method fails.

Timing Scope Matters More Than Stop() Micro-Cost

The call to Stop() itself is not the interesting performance issue. The real question is whether you are timing the correct scope.

For example, decide whether your measurement should include:

• input validation
• logging
• exception handling
• disposal and cleanup

Stopping the stopwatch deliberately at the boundary you care about is the cleanest way to express that intent.

Common Pitfalls

The most common mistake is leaving the stopwatch running while doing logging or result formatting and then assuming the measurement still reflects only the target work.

Another mistake is focusing on whether Stop() is "required" instead of defining the exact measurement boundary clearly.

A third pitfall is benchmarking with one-off stopwatch measurements when a proper benchmarking tool would be more reliable.

If the code is performance-critical and repeatable, a dedicated benchmark harness is usually a better choice than ad hoc stopwatch timing inside production methods.

That keeps measurement logic out of ordinary application flow.

Summary

• If you are done measuring, call Stop().
• Omitting Stop() can still work in simple cases, but it is less explicit.
• 'Stop() helps freeze the intended timing window and prevents accidental extra measurement.'
• Use try and finally when you want the stopwatch stopped even on errors.
• Clear timing scope matters more than any tiny overhead of the Stop() call itself.