是否有任何已知的技术（以及与它们相关的资源，如研究论文或博客条目）描述了如何动态以编程方式检测导致性能退化的代码部分，如果可能的话，在JVM或其他一些虚拟机环境中（可以相对容易地应用仪器等技术）？
特别是，当拥有大型代码库和更多数量的项目提交者（例如，操作系统，语言或某些框架）时，有时很难找到导致性能下降的更改。像this one这样的论文在描述如何检测性能回归（例如在某段代码中），但不是如何动态查找方面有很长的路要走。项目中的一段代码因某些提交而改变，导致性能下降。
我在想这可以通过检测程序的各个部分来检测导致回归的确切方法，或者至少缩小性能回归的可能原因范围。
有没有人知道有关此事的任何内容，或使用此类性能回归检测技术的任何项目？
编辑：
我指的是these lines的内容，但是对代码库本身进行了进一步的分析。
答案 0 :(得分：2)
也许并不完全是你所要求的，但是在我为极端性能要求工作的项目中，我们使用单元测试框架编写了性能测试，并将它们粘贴到我们的持续集成环境中。
这意味着每次办理登机手续时，我们的CI服务器都会运行经验证我们没有放慢功能超出我们可接受范围的测试。
这并不完美 - 但它确实让我们能够随时关注我们的关键性能统计数据，并且它会检查影响性能的检查。
为性能定义“可接受的界限”更像是一门艺术而非科学 - 在CI驱动的测试中，我们采用了一种基于硬件规范的相当简单的方法;如果性能测试超过100个并发用户的响应时间超过1秒，我们将失败。这引起了一系列低调的水果性能问题，并给了我们对“生产”硬件的相当程度的信心。
我们明确没有在签入之前运行这些测试，因为这会减慢开发周期 - 迫使开发人员在签入之前运行相当长时间运行的测试，鼓励他们不要经常检查。如果不部署到已知的硬件，我们也不相信我们会得到有意义的结果。
答案 1 :(得分：1)
使用像YourKit这样的工具，您可以拍摄测试或应用程序性能细分的快照。如果再次运行应用程序，则可以比较性能细分以找出差异。
性能分析更像是一门艺术而非科学。我不相信你会找到一个工具来告诉你究竟是什么问题，你必须使用你的判断。
例如，假设您的方法花费的时间比以前长得多。是因为方法已经改变，还是因为它被称为不同的方式，或者更常见。你必须使用自己的判断力。
答案 2 :(得分：1)
JProfiler允许您查看已检测方法的列表，您可以按平均执行时间，固有时间，调用次数等对其进行排序。我认为如果将此信息保存在版本上，则可以对回归进行一些了解。如果测试不完全相同，那么分析数据将不准确。
答案 3 :(得分：1)
有些人意识到找到（而不是测量）过度时间的原因的技术。
It's simple, but it's very effective.
基本上就是这样：
如果代码很慢，那是因为它花了一些时间F（比如20％，50％或90％）来做X不必要的事情，因为如果你知道它是什么，你就会吹它离开了，节省了一小部分时间。
在一般时间内它很慢，在任何随机纳秒时，它做X的概率是F.
所以，只需要几次，然后问它正在做什么。 并问它为什么这样做。
典型的应用程序几乎花费所有时间等待一些I / O完成，或者某些库函数返回。
如果你的程序中有些东西需要花费太多时间（并且有），那么几乎可以肯定的是，你会在调用堆栈中找到一个或几个函数调用，这是因为糟糕的原因。