调试期间Visual Studio 2010代码分析

Question

我正在研究VS2010 Professional中的Visio Addin,我在调试应用程序时正在寻找热点(特别是在COM对象周围).我找到了许多可以分析现有.NET应用程序的分析器,但没有一个(我见过)支持调试.此外,因为这是一个.NET加载项而不是完整的独立可执行文件,所以我不确定它们是如何公平的.

我调查过的Profilers:

1. EQATEC
2. Slimtune
3. CLR
4. nprof
5. VS2010 Performance Profiler - 请注意,当我使用Professional时,这需要Ultimate或Premium.

有没有人找到可以在VS2010调试会话期间使用的分析器？

Answer 1

我之前已经提到了这一点,其他人也是如此.

如果您的目标是提高性能,以挂钟时间来衡量,到目前为止,最好的工具只是调试器本身及其"暂停"按钮.让我告诉你原因.

首先,让我们看一个好的剖析器

在个人资料中,ANTS可能和它们一样好.当我在应用程序上运行它时,屏幕顶部如下所示:

请注意,您必须选择要查看的时间范围,并且必须选择是否要查看CPU时间或文件I/O时间.在这段时间内,您会看到以下内容:

试图表明ANTS认为什么是"热门路径",只考虑CPU时间.当然它强调包容性的"儿童时间(%)",这很好.在像这样的大代码库中,注意自我时间"时间(%)"是多么小？这是典型的,你可以看到原因.

这说明你应该忽略具有低包容百分比的函数,因为即使你可以将它们减少到无操作,你在该时间间隔内的总时间也会下降不超过它们的包含百分比.

所以你看看具有高包容性百分比的函数,你试着在它们中找到一些东西,使它们花费更少的时间,通常是a)让它们减少对子函数的调用,或者b)让函数本身被调用减.

如果你发现并修复它,你可以获得一定的加速百分比.然后你可以再试一次.当你找不到任何可以修复的东西时,你宣布胜利,并将你的探查器收起一天.

请注意,可能存在其他问题,您可以修复以获得更快的速度,但如果探查器无法帮助您找到它们,则您认为它们不存在.这些可能是真正的大睡眠者.

现在让我们来看一些手动样本

在我困扰我的阶段,我只是随机地暂停了应用程序六次因为它让我等待.每次我把调用堆栈的快照,和我花了好长时间看程序做什么,它为什么这样做.其中三个样本看起来像这样:

外部代码
Core.Types.ResourceString.getStringFromResourceFile线506
Core.Types.ResourceString.getText线423
Core.Types.ResourceString.ToString线299
外部代码
Core.Types.ResourceString.getStringFromResourceFile线528
Core.Types.ResourceString.getText线423
核心.Types.ResourceString.ToString第299行
Core.Types.ResourceString.implicit运算符字符串第404行
SplashForm.pluginStarting第149行
Services.Plugins.PluginService.includePlugin第737行
Services.Plugins.PluginService.loadPluginList第1015行
Services.Plugins.PluginService.loadPluginManifests行1074
Services.Plugins.PluginService.DoStart第95行
Core.Services.ServiceBase.Start第36行
Core.Services.ServiceManager.startService第1452行
Core.Services.ServiceManager.startService第1438行
Core.Services.ServiceManager.loadServices第1328行
Core.Services. ServiceManager.Initialize Line 346
Core.Services.ServiceManager.Start第298行
AppStart.Start第95行
AppStart.Main第42行

这是它正在做的事情.它正在读取资源文件(即I/O,因此查看CPU时间不会看到它).它阅读它的原因是获取插件的名称.插件名称在资源文件中的原因是未来可能需要将该字符串国际化.无论如何,它被提取的原因是在加载插件期间可以在启动画面上显示名称.据推测,原因是,如果用户想知道这么长时间,那么启动画面会向他们展示正在发生的事情.

这六个样本证明,如果没有显示名称,或者显示的名称是以更有效的方式获得的,那么应用程序的启动速度将大约翻倍.

我希望你能看到没有通过显示测量工作的分析器可以很快产生这种见解.

即使分析器显示包含时间百分比的壁挂时间,而不是CPU,它仍然会让用户试图弄清楚正在发生的事情,因为在总结例程的时间时,它几乎失去了说明的所有解释上下文如果它正在做什么是必要的.

当仅查看摘要统计数据并查看代码时,人类的倾向是说"我可以看到它正在做什么,但我认为没有任何方法可以改进它."

那么"统计意义"呢？

我一直听到这个,它来自天真的'关于统计数据.

如果六个样本中有三个显示出问题,则表示该问题最常使用的实际百分比是3/6 = 50%.这也意味着如果你多次这样做,平均成本将是(3 + 1)/(6 + 2),这也是50%.如果节省50%的时间,则可以节省2倍的速度.成本可能只有20%,在这种情况下,加速可能只有1.25倍.成本可能高达80%的概率相等,在这种情况下,加速将是5倍(!).所以是的,这是一场赌博.加速可能低于估计值,但不会为零,并且同样可能非常大.

如果需要更高的精度,可以采集更多样本,但如果牺牲了检查样本以获得统计精度的洞察力,则可能无法找到加速.

PS 此链接显示了找到所有问题的关键重要性- 不会遗漏任何问题.