这些都是衡量时间的好方法，但这只是发现瓶颈的一种非常间接的方法。

在线程中找到瓶颈的最直接方法是让它运行，当它正在做任何让您等待的事情时，使用暂停或中断键停止它。这样做几次。如果你的瓶颈占用了X%的时间，那么X%就是你在每次快照中捕捉到它的概率。

这里有一个更完整的解释，它是如何以及为什么工作的

这是正确的方法:

using System;
using System.Diagnostics;

class Program
{
    public static void Main()
    {
        Stopwatch stopWatch = Stopwatch.StartNew();

            // some other code

        stopWatch.Stop();

        // this not correct to get full timer resolution
        Console.WriteLine("{0} ms", stopWatch.ElapsedMilliseconds);

        // Correct way to get accurate high precision timing
        Console.WriteLine("{0} ms", stopWatch.Elapsed.TotalMilliseconds);
    }
}

要了解更多信息，请使用秒表而不是DataTime来获得准确的性能计数器。

Visual Studio Team System有一些功能可以帮助解决这个问题。从本质上讲，您可以编写单元测试，并将它们混合在不同的场景中，作为压力或负载测试的一部分对您的软件运行。这可能有助于识别对应用程序性能影响最大的代码区域。

微软的模式和实践小组在Visual Studio团队系统性能测试指南中提供了一些指导。

这不够专业:

Stopwatch sw = Stopwatch.StartNew();
PerformWork();
sw.Stop();

Console.WriteLine("Time taken: {0}ms", sw.Elapsed.TotalMilliseconds);

更可靠的说法是:

PerformWork();

int repeat = 1000;

Stopwatch sw = Stopwatch.StartNew();
for (int i = 0; i < repeat; i++)
{
   PerformWork();
}

sw.Stop();

Console.WriteLine("Time taken: {0}ms", sw.Elapsed.TotalMilliseconds / repeat);

在我的实际代码中，我将添加GC。收集调用以将托管堆更改为已知状态，并添加Sleep调用，以便在ETW配置文件中轻松分离不同的代码间隔。

秒表也一样，它好多了。

关于性能度量，你还应该检查你的“// Some Execution Process”是否是一个非常短的过程。

还要记住，“// Some Execution Process”的第一次运行可能比后续运行慢得多。

我通常通过在循环中运行1000次或100万次来测试一个方法，我得到的数据比运行一次要准确得多。

我刚刚在Vance Morrison的博客上找到了一篇关于他写的CodeTimer类的文章，这个类可以让使用StopWatch变得更容易，并在旁边做一些整洁的事情。