logo标签列表

一个C#/.NET性能分析器应该具备哪些特点？

c#.netperformanceprofiler
32

这可能有点广告成分，不太客观，但问题是真诚的。在过去的两个月中，我一直在开发一个名为SlimTune Profiler的新开源.NET性能分析工具(http://code.google.com/p/slimtune/)。

尽管市面上有很多性能分析工具可用，但我并不是非常满意。我已经基于现有产品做了一些初步工作，但我觉得这里是个很好的地方来问：你到底想从性能分析工具中获得什么？

我来自实时图形和游戏领域，所以对我来说，性能分析工具尽可能快速非常重要。否则，游戏就会变得无法玩耍，而对一个无法流畅运行的游戏进行性能分析往往没有多少启示。因此，我愿意牺牲一些准确性。我甚至不关心异常。但我不太了解其他类型应用程序的开发人员感兴趣的内容。对您来说，有哪些功能是必不可少的？现有工具存在哪些问题？

再次道歉如果这超出了StackOverflow的范围，但它一直是我极其有用的资源，这里也有非常广泛的开发人员群体。

7
我认为这是一个很合理的问题，尤其是考虑到你正在为开发人员构建软件，并且它是开源的。非常期待答案！ - JoshJordan
赞同。这是一个程序员的工具。 - Preet Sangha
我真的很喜欢它是开源的，我会看看它与dotTrace相比如何。 - Athiwat Chunlakhan
@Promit：我刚刚对这个主题进行了更多的评论，你可能会觉得有趣：https://dev59.com/fEjSa4cB1Zd3GeqPFnvP#1149010 - Mike Dunlavey
14个回答
17

我的需求：

  • 能够在不影响应用程序的情况下收集统计数据 - 比如，不占用内存，允许在受检测的应用程序之外收集数据
  • 能够简单且可重复地指定测量内容（数据驱动）
  • 可自动化，以便我能够重复测量而无需点选和 UI
  • 使我们能够理解与 WPF 和其他声明性技术（如 DLR 或 WF）相关的问题
  • 不需要安装 - 不使用 GAC、MSI 等，如果可以通过网络运行则更好
  • 从一开始就支持 64 位
  • 不要尝试了解所有可能进行的分析 - 鼓励建立生态系统。如果原始统计数据可以使用其他工具进行分析，则更好。
  • 如果有 UI，则应该是好的 - 但是统计数据才是重要的。因此，不要花费太多时间在 UI 上，把核心分析功能做好。
    • 支持对非直接执行文件（如服务和 Web 应用程序）进行简单的应用程序性能分析。

希望有以下功能：

  • 考虑跨应用程序支持 - 大型应用程序通常需要了解跨多个可执行文件的应用程序性能行为。如果您的分析工具能够轻松关联这些数据，那就更好了。
我已经完成其中一些——数据通过套接字从配置目标广播到本地或远程前端。后备数据存储是SQL Server Compact，未来会有更多选项。我将考虑开发一个强大的自动化系统，因为我认为这是一个许多现有工具缺失的极其重要的功能，而数据驱动也将与之相关联。 - Promit
如果你说的是CE的后备存储，那么需要安装吗？ - Preet Sangha
@Promit - 你有产品了吗？ - Preet Sangha
11

我的愿望清单：

  • 极易使用 - 简单（但功能强大）的图形用户界面
  • 出色的性能 - 能够在极度重负下分析应用程序
  • X64和X32支持
  • 理解SQL，能够为我所有的SQL调用提供堆栈跟踪和持续时间，结合SQL。
  • 易于进行性能分析，无需经过复杂的重新编译应用程序的流程
  • 易于对服务、网站和作为副作用启动的进程进行性能分析
  • “生产模式”允许您从基于生产的系统中收集关键统计信息。
    • “自动瓶颈发现器”：针对生产应用程序运行并使用启发式算法确定哪些方法较慢。
  • 线程级别的分析，告诉我哪些线程正在完成所有的工作以及它们在哪里执行。
  • 在各种粒度下进行性能分析，允许执行“便宜”的分析来收集关键信息，并进行粒度更细的分析。
  • 异常跟踪器，允许我跟踪应用程序中抛出的所有异常（关键统计信息和详细信息）
  • 线程级别的分析 - 允许我对应用程序中的单个线程进行性能分析。
4
下载Visual Studio 2010 Beta 1的Team Suite版本（免费6个月或更久），并对C#应用程序进行分析。
相信我。 :)
编辑：逐行模式帮助我隔离出一个导致性能问题的运算符。我本可以在没有逐行突出显示的情况下找到它，但是当你可以滚动屏幕并查看使用它的热点代码时，你可以如此轻松地修复它。
哦，如果你想要反馈/帮助，请单独联系我。
摘要视图：选择CPU图表中的任何部分进行过滤。 Summary View （来源：280z28.org） 我喜欢边栏的逐行模式： Details View （来源：280z28.org）
哦，很漂亮。我不知道我是否会很快实现逐行功能——对我来说，这似乎是一项低产出高成本的功能。但顶部视图非常华丽，我肯定会从中汲取灵感。是时候好好利用我的MSDN订阅了。 - Promit
这是一个不错的截图。对我来说，逐行阅读非常重要，因为即使是简单的东西，如果被调用足够多次，也可能需要很长时间，所以知道时间花在哪里很重要。 - Ian
逐行调试通常太昂贵了，但是如果能够针对特定函数启用它，那将是非常好的。我发现很烦人的是，如果我想找出一个函数中哪一行很慢，我需要经常滥用“提取方法”。 - Brian
@Brian：有些东西告诉我你没有使用过VS10分析器。那个东西就是你声称它很慢。至少对于采样模式来说，它并不慢。 :D - Sam Harwell
4

有一个免费的.Net分析器，叫做EQATEC Profiler，我一直想使用。

我希望它能够与Mono兼容。我已经开始涉足Mono，拥有一个同时支持.Net和Mono的分析器将是非常棒的！

3
2

我再添加一个非常实用的功能。创建一个简单的程序集（assembly），其中包含可用的 Mark(string) 函数。如果应用程序调用了该方法，则您可以选择仅查看从该方法到（结尾|某个其他指定标记）的结果。另一种可能性是使用 BeginSequence 和 EndSequence 等函数。如果能够指定标记是否仅适用于当前线程或所有线程，那就更好了。

由于我来自游戏行业，因此这个问题非常重要——逐帧分析是绝对关键的。 - Promit
2

我希望性能分析器具备以下功能：

  • 可在32位和64位系统上运行
  • 应具有所有层（客户端、应用程序服务器、数据库）的组件，并且可以在它们之间建立关联。例如，可以查看更改如何影响其他层。这有助于决定在哪个层实现特定功能。
  • 命令行接口，以便与自动化场景（构建服务器、压力测试等）一起使用
  • 应具有轻量级采样模式和更精确的插装模式。第二种模式对执行测量的影响应尽可能小。
  • 图形用户界面易于使用，并且应生成必要的配置文件以便以命令行模式使用
  • 生成标准格式的结果（如果存在此类格式），以便我可以使用其他工具消耗结果
  • 还应生成或导出结果到Visual Studio的格式（*.vsp）
  • 比较两个或多个结果文件，以查看代码库的演变或退步
  • 收集并将目标应用程序数据与运行在每个目标机器上的其他进程的PerfMon数据相关联，以识别并发资源使用（内存、处理器、磁盘和网络I/O）
  • 确定阈值，当一个特定场景需要更长时间时，应激活某些警报机制。例如，如果一个特定场景的执行时间超过指定时间，则应向某人发送电子邮件。
  • 能够连接到正在运行的进程并从中分离出采样数据，而不会干扰目标应用程序。这对于在生产现场使用非常重要。
2

Phsr已经提到了EQATEC Profiler。

它有一个我喜欢的功能，即使没有阅读任何文档或完全不关注我正在做什么，我也能成功地从头到尾地对应用程序进行分析。可用性是一件美妙的事情。请注意如何添加所有那些花哨的选项...不要在此过程中破坏可用性。

2
多年前，我建立了一个性能分析器，并在回答其他问题时在SO上描述了它，但我现在无法找到该问题。这个分析器基于我使用数十年的技术，其中这里提供了一个示例。它基于堆栈采样，关键在于如何呈现信息以及用户的思考过程。
我认为需要质疑并加强学校（由于教授们很少接触实际软件）所教授的有关性能调优的一般信念，并继续通过50,000程序员不会错的现象。从巡游SO中您可能会发现，我远非孤单。
我认为性能分析技术正在逐渐发展（在我看来是更好的方向），朝着堆栈采样和探索结果的方式发展。以下是我依赖的见解（您可能会感到有些不适）：
揭示性能问题以便修复和测量性能是两个完全不同的任务。它们是手段和目的，不应混淆。
要揭示性能问题，需要找到哪些活动占用了大量挂钟时间，并且可以用更快的东西替换。
这些活动的好处在于，它们需要时间的事实使它们暴露于程序状态的随机时间样本中。
如果在您关心的时间间隔内进行采样，则不需要太多的样本。即，等待用户输入时没有取样的意义。为此，在我的分析器中，我让用户使用键触发样本。
您不需要太多的样本的原因是这样的。任何给定的性能问题都会在感兴趣的时间间隔内占用一些挂钟时间的X分数。在该间隔内进行的随机抽样具有“捕捉它在行动中”的X概率，因此如果采取N个样本，则预期在行动中捕捉到的样本数量为NX。该样本数量的标准差为sqrt（NX（1-X））。例如，如果N = 20，X = 20％，则可以预计大约有2到6个样本显示问题。这为您提供了一个不精确的问题度量，但它确实告诉您值得修复，并且它为您提供了一个非常精确的位置，无需进一步的侦探工作。
问题通常表现为比必要的更多的函数、过程或方法调用，特别是随着软件变得越来越大，有更多的抽象层和因此有更多的堆栈层。我首先查找的是出现在多个堆栈样本中的调用站点（而不是函数，而是调用语句或指令）。它们出现在的堆栈样本越多，花费就越高。我查找的第二件事是“它们可以被替换吗？”如果它们绝对不能被更快的东西替换，那么它们就是必要的，我需要寻找其他地方。但是，它们经常可以被替换，并且我获得了很好的加速。因此，我仔细查看特定的堆栈样本，而不是将它们聚合成测量结果。
递归不是问题，因为指令成本的原则是它在堆栈上的时间百分比相同，即使它调用自身。
这不是我一次做的事情，而是在连续的传递中进行的。我修复的每个问题都会使程序花费更少的时间。这意味着其他问题成为时间的更大分数，使它们更容易找到。这种效果会累积，因此通常可以实现戏剧性的累积性能改进。
我还可以继续下去，但我祝你好运，因为我认为需要更好的分析工具，而您有很好的机会。
1

如果能够将与.NET相关的性能监控措施从Perfmon集成进来，那就太好了，这样你就可以避免在perfmon和应用程序中进行“双重”监控。对于所有与内存相关的项目，这尤其有用。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接