解决代码中的瓶颈问题

Question

所有

鉴于您在功能和实现方面根本不了解的代码，您将如何找到该代码中的性能瓶颈？请列出您可能正在使用的任何特定工具/标准方法。

Answer 1

您也应该使用分析，具体取决于平台：

• .NET：Visual Studio性能工具，JetBrains dotTrace
• Java：JProfiler

上述工具适用于应用程序，但功能各不相同。例如，Visual Studio可以根据层汇总性能数据。

如何解决问题在很大程度上取决于程序的类型以及您所面临的性能问题。但基本上，你将重复以下周期：

• 记录性能数据（可能会更改记录数据的更高/更低粒度的设置）
• 识别消耗大部分应用时间的热点
• 也许使用反向调用表来识别热点的调用方式，以及代码中的位置
• 尝试重构/优化热点
• 重新开始，检查优化的效果。

上述周期可能需要多次迭代才能达到可接受性能的程度。

请注意，这些工具提供了许多不同的功能和方法来查看性能数据或记录它们。如果您不了解应用程序的内部结构，则应该开始使用工具提供的不同功能和报告，以便您可以确定优化的位置。

Answer 2

我假设您拥有源代码，并且您可以在调试器下运行它，并且有一个“暂停”按钮（或Ctrl-C或Esc），您只需将其停在轨道上即可。

我这样做了好几次让它等了，比如10或20，每次研究调用堆栈，也许还有其他状态信息，所以我可以用口头的方式解释它在做什么以及为什么。< / p>

这是重要的事情 - 要知道为什么正在做它正在做的事情。

通常我看到的是，例如，20％，或50％，或90％的样本，它正在做某事，而且通常可以更有效地完成或根本不做。所以修复那个东西可以减少（大致）百分比的执行时间。 问题越大，你看得越快。 在限制中，您可以在1个样本中诊断无限循环。

这可以从profiler-aficionados中得到很多抨击，但是尝试它的人知道它非常有效。它基于不同的假设。 如果你在房间里寻找大象，你不需要测量他。 这是more detailed explanation和list of common myths。

下一个最好的事情是一个壁挂式堆栈采样器，它会报告线路或指令级别的百分比，例如Zoom或LTProf，但它们仍会让您感到困惑为什么

祝你好运。

Answer 3

使用差异分析。选择程序的一部分并人为地减慢它（添加一堆代码，除了浪费时间之外什么都不做）。重新运行测试并观察结果。为程序的各个方面执行此操作。如果添加延迟不会改变性能，那么这方面不是您的瓶颈。导致最大性能损失的方面可能是寻找瓶颈的第一个方面。

如果在程序运行时可以调整延迟代码的严重性，则效果会更好。您可以增加和减少人工延迟，看看它如何影响性能。如果您遇到一个测试，其中观察到的性能的变化似乎线性地遵循人为延迟，那么该程序的那个方面可能是您的瓶颈。

这只是一个穷人的做法。最好的方法可能是使用分析器。如果您指定了语言和平台，则有人可能会推荐一个好的分析器。

Answer 4

对于您正在使用的系统类型没有任何想法，这些无偿建议：

• 尝试建立有关系统如何扩展的知识：如何处理10倍的用户，如何处理100倍的数据，或者使用100倍的网络环境......

• 在系统中找到正确的“探测”点：分布式系统当然比桌面应用程序更难分析。

• 找到合适的技术来分析从探针接收的数据。 Profilers在可视化瓶颈功能方面做得很好，但我可以想象它们对您的云服务毫无帮助。尝试以图形方式显示您的数据，您的大脑在识别图形模式方面比在数字方面更好，更不用说文本了。

• 哦 - 找出期望是什么！如果应用程序每年只启动三次，那么优化应用程序的启动时间是没有用的。

Answer 5

我会说步骤是：

1. 根据系统使用情况或采访用户，确定实际的慢功能。这应该缩小问题范围（如果没有人抱怨，也许没有问题。）
2. 运行代码分析器（例如dotTrace / Compuware）和数据层分析器（例如SQL Profiler，NHibernate Profiler，具体取决于您使用的内容。）在实际使用一天左右后，您应该获得一些好的结果。
3. 如果您无法从中了解问题，请在下一个实时版本中添加一些额外的秒表代码，以记录每个操作中的毫秒数。

这应该可以很好地描述应该合并为一个的多个数据库查询，或者可以移出内部循环或预先计算的代码等。