使用秒表分析.NET应用程序

Ken*_*rey 11 .net c# profiling stopwatch

似乎没有免费的*.NET性能分析器可以逐行进行分析.因此,我正在研究使用秒表进行分析.

*在自由中免费,即许可包括商业应用.

编辑:回应那些告诉我"买一个探查器"的人,我想,但如果我可以花那么多钱,我会花在别的东西上.我试图说服我的老板说一个分析器值得,但运气不好.这个问题主要基于好奇心.我永远不会认为秒表是真正的探查者的替代品.

我有一个小测试应用程序(用C#编写),用于衡量在每行使用秒表时的性能差异.测试代码是这样的:

int n = 100;
BigInteger f = 1;
for (int i = n; i > 1; i--)
{
    f *= i;
}
Run Code Online (Sandbox Code Playgroud)

以下是完整代码:http://pastebin.com/AvbQmT32

我为每行代码都有一个秒表.这是我的"探查者".我整个节目也有一个秒表.这是我的'profiler profiler'.

我将程序配置为发布模式,任何CPU(在x64计算机上),并禁用优化.

当我在禁用探查器的情况下运行程序时,我会得到这样的结果:

             Line             |  Ticks
------------------------------|----------
                              |
Total time:                   |       359
Run Code Online (Sandbox Code Playgroud)

当我在启用了探查器的情况下运行它时,我会得到这样的结果:

             Line             |  Ticks
------------------------------|----------
                              |
int n = 100;                  |         3
BigInteger f = 1;             |        12
for (int i = n; i > 1; i--)   |       325
{                             |
    f *= i;                   |       539
}                             |
                              |
Total time:                   |      1710
Stopwatch overhead:           |       831
Run Code Online (Sandbox Code Playgroud)

理想情况下,在两种情况下花在代码上的时间应该相等,但看起来Stopwatches的开销在它们自己的经过时间内出现.

现在,需要对程序的每一行进行剖析通常没有意义,因为它通常可以通过分而治之的方法更好地工作.您通常可以从分析代码块开始,并缩小任何性能问题.

此外,在大多数应用程序中,平均代码行将比测试程序中的代码慢很多.这意味着秒表开销会减少.

但是,使用Stopwatches时仍然存在开销,特别是如果你经常使用.

所以问题是:

使用Stopwatches进行性能分析的最有效方法是什么?如何最大限度地减少开销?围绕一个声明包装秒表是否值得?

感谢您的反馈.

Dav*_*son 2

首先,您的结果一点也不令人惊讶。如果您使用商业分析器,您会看到类似的情况:您的程序在进行分析时比不进行分析时运行时间要长得多。分析器设置得越精细,预计花费的时间就越长。当您考虑到像“i > 1”和“i--”这样的语句可能会作为单处理器指令执行时,很明显为什么分析特定行的执行时间可能比执行该行本身花费更长的时间。

事实上,分析会增加程序的整体运行时间,这一点不必担心;正如其他几个人提到的,重要的不是程序运行的绝对时间,而是比较各个部分的运行时间以找到瓶颈。但还有另一个担忧。秒表将使用底层操作系统中的高频计时器(如果可用);但即便如此,也可能还不够高。我的 Windows 7 64 位 i5-2400(四核 3.10 GHz)上的高频计时器每秒滴答 3,020,556 次。听起来很多;但按照这个速度,处理器可以在滴答之间执行一千条指令。这意味着,如果您尝试测量执行单个指令所需的时间,那么您要么会低于,要么会超过。

您最好在方法级别进行分析。即使这样,您也会遇到频率问题,特别是如果您有小型的精心分解的方法。但结果会比线路层面的结果更可靠;一旦确定了导致瓶颈的方法,您就可以直接检查它以确定如何优化它以提高性能。

所有这些都忽略了与一般性能分析相关的许多警告,这超出了本文的范围。确保你对这个主题进行了额外的研究,以了解你应该如何解释你得到的任何结果。举个简单的例子,您的分析可能会显示您的程序中的大部分时间都花在了特定的方法上;但这是否意味着方法本身就是问题,或者其他方法经常调用它?回答这类问题才是分析的真正困难所在。