我在剖析中是个假人，请告诉我你的人如何分析你的申请。哪一个更好，分析整个应用程序或隔离？如果选择是隔离你如何做到这一点？
答案 0 :(得分：5)
尽可能分析整个应用程序，运行真实（典型）工作负载。除此之外，您还有可能获得结果，导致您将优化工作集中在错误的位置。
修改
在分析整个应用程序时，获取正确的结果难道不是很难吗？所以测试结果取决于用户交互（按钮点击等）而不是使用自动任务？告诉我，如果我错了。
获取“正确结果”取决于您如何解释分析数据。例如，如果要分析交互式应用程序，则应该确定配置文件的哪些部分对应于等待用户交互，并忽略它们。
在部分中分析应用程序时存在许多问题。例如：
通过预先确定要分析的应用程序的哪些部分，您无法很好地了解不同部分的相对贡献，并且您可能会在错误的部分上浪费精力。
您几乎必须使用人工工作负载。每当您这样做时，存在工作负载不能代表“正常”工作负载的风险，并且您的分析结果存在偏差。
在许多应用程序中，瓶颈是由于应用程序的各个部分彼此交互，或者与I / O或垃圾收集交互的方式。分别对应用程序的不同部分进行概要分析可能会错过这些交互。
......我正在寻找的是技术
粗略地说，您从配置文件数据中确定的最大“热点”开始，然后向下钻取，直到您发现为什么在某个区域花费了太多。如果您的分析工具可以自上而下和自下而上聚合并呈现数据，那将非常有用。
但是，最终从分析证据（热点，堆栈快照等）到根本原因，补救措施往往取决于经验带来的实践知识和直觉。
（是的......我有点胡思乱想。但我的观点是，没有神奇的公式可以做到这一点。最终，你必须使用你的大脑......就像调试一个复杂的时候一样的应用程序。）
答案 1 :(得分：2)
首先，我只是用手表计时以获得整体测量结果。
然后我在调试器下运行它并取stackshots。这些操作告诉我哪些代码行负责大部分时间。特别是，这意味着在没有真正需要的情况下调用函数的行，以及我可能没有意识到的I / O.
因为它向我展示了需要时间并且可以更好地完成的代码行，所以我解决了这些问题。
然后我从顶部开始看看我实际节省了多少时间。我重复这些步骤，直到我再也找不到a）占用大量时间的事情，并且b）我可以修复。
这被称为“穷人的剖析”。这个小秘密不仅便宜，而且非常有效，因为它避免了common myths about profiling。
P.S。如果它是一个交互式应用程序，所有这一切只是对它的一部分很慢，就像你按下“执行有用的东西”按钮，并在几秒钟后完成。在等待你时，没有必要拍摄叠加照片。
P.P.S。假设某些活动应该更快，但是完成得太快以至于不能进行叠加，就好像它需要一秒但是应该只需要几分之一秒。然后你可以做的是（暂时）在它周围包裹一个 for 循环，10或100次迭代。这将花费足够长的时间来获取样品。在你加速之后，移除循环。
答案 2 :(得分：0)