performance - 防止R中的性能下降

Question

什么是检测R包中性能下降的良好工作流程？理想情况下，我正在寻找与R CMD check集成的东西，当我在代码中引入了显着的性能下降时，它会提醒我。

总的来说，什么是好的工作流程？还有哪些其他语言提供了好的工具？它可以建立在顶级单元测试之上，还是通常单独完成？

Answer 1

这是一个非常具有挑战性的问题，也是我经常处理的一个问题，因为我交换了程序包中的不同代码以加快处理速度。有时性能退化会伴随算法或实现的变化而出现，但是它也可能由于所使用的数据结构的变化而出现。

What is a good workflow for detecting performance regressions in R packages?

就我而言，我倾向于尝试使用非常特定的用例，并使用不同的固定数据集。正如Spacedman所写，拥有固定的计算系统非常重要，但这几乎是不可行的:有时，一台共享计算机可能具有其他进程，这些进程会使速度降低10％到20％，即使它看起来很空闲。

我的步骤:

标准化平台(例如，一台或几台计算机，特定的虚拟机或虚拟机+特定的基础架构，例如Amazon的EC2实例类型)。

标准化将用于速度测试的数据集。

创建涉及非常少的数据转换的脚本和固定的中间数据输出(即保存到.rdat文件)。我的重点是某种建模，而不是数据操纵或转换。这意味着我想为建模函数提供完全相同的数据块。但是，如果数据转换是目标，那么在不同版本的程序包测试中，确保预转换/操纵的数据尽可能接近标准。 (请参阅this question中的备注，缓存等示例，这些示例可用于标准化或加快非焦点计算。它由OP引用了多个程序包。)

重复测试多次。

相对于固定基准来缩放结果，例如执行线性回归，对矩阵进行排序等的时间。这可能允许基础结构的“局部”或瞬时变化，例如，可能是由于I / O，内存系统，相关程序包等引起的。

尽可能严格地检查概要分析输出(有关更多见解，请参见this question，另请参见OP中的工具)。

Ideally, I'm looking for something that integrates with R CMD check that alerts me when I have introduced a significant performance regression in my code.

不幸的是，我对此没有答案。

What is a good workflow in general?

对我来说，它与一般的动态代码测试非常相似:输出(在这种情况下，执行时间)是否可重现，最佳且透明？透明来自于了解什么会影响整体时间。这是Mike Dunlavey的建议很重要的地方，但我更喜欢使用线路轮廓仪进行进一步分析。

关于线路分析器，请参阅my previous question，该示例在其他示例中引用了Python和Matlab中的选项。检查时钟时间非常重要，但跟踪内存分配，执行该行的次数以及调用堆栈深度也非常重要。

What other languages provide good tools?

几乎所有其他语言都有更好的工具。 :)诸如Python和Matlab之类的解释性语言具有良好且可能熟悉的工具示例，可以将其用于此目的。尽管动态分析非常重要，但是静态分析可以帮助确定可能存在一些严重问题的位置。 Matlab有一个很棒的静态分析器，可以报告对象(例如 vector ，矩阵)何时在循环内部增长。仅通过动态分析来找到它是很糟糕的-您已经浪费了执行时间来发现类似的东西，并且如果您的执行上下文非常简单(例如，仅几次迭代或小的对象)，则并不总是可以看出。

至于与语言无关的方法，您可以查看:

Valgrind和cachegrind

监视磁盘I / O，脏缓冲区等。

监视RAM(Cachegrind很有用，但是您可以监视RAM分配以及有关RAM使用情况的许多详细信息)

多核的使用

Is it something that can be built on top unit testing, or that is usually done separately?

这很难回答。对于静态分析，它可以在单元测试之前发生。对于动态分析，可能需要添加更多测试。可以将其视为顺序设计(即来自实验设计框架):如果执行成本似乎在一定的统计差异范围内是相同的，则无需进一步测试。但是，如果方法B的平均执行成本似乎大于方法A，则应该执行更严格的测试。

更新1:如果我这么大胆，我建议您提出另一个问题，即:“比较两个版本的程序包的执行时间有哪些陷阱？”这类似于假设实现相同算法的两个程序应具有相同的中间对象。这不是完全正确的(请参阅 this question-不是我在这里提倡自己的问题，要使事情变得更好和更快就很难了……导致有关此主题的多个SO问题:)。以类似的方式，由于实现以外的因素，同一代码的两次执行可能会消耗不同的时间。

因此，在同一语言中或在不同语言中，在同一执行实例中或在“相同”实例中可能发生的一些陷阱，可能会影响运行时:

垃圾回收-不同的实现或语言可能会在不同的情况下影响垃圾回收。尽管这可能非常依赖于上下文，参数，数据集等，但这会使两个执行看起来有所不同。GC过多的执行看起来会比较慢。

在磁盘，主板级别(例如L1，L2，L3缓存)或其他级别(例如备忘录)进行缓存。通常，第一次执行将被罚款。

Dynamic voltage scaling-这个很烂。当出现问题时，这可能是最难发现的难题之一，因为它可以很快消失。它看起来像是缓存，但不是。

您不知道的任何作业优先级管理器。

一种方法使用多个内核，或者在内核或CPU之间如何分配工作方面做一些巧妙的事情。例如，在某些情况下，将进程锁定到核心可能很有用。就此而言，一个R包的执行可能更幸运，另一个包可能非常聪明...

未使用的变量，过多的数据传输，肮脏的缓存，未刷新的缓冲区，...等等。

关键结果是:理想情况下，我们应该如何测试预期值的差异，以防止由于订单效应而产生的随机性？好吧，非常简单:回到实验设计。 :)

当执行时间的经验差异与“预期”差异不同时，启用附加的系统和执行监控功能非常好，这样我们就不必重新运行实验，直到脸色变蓝为止。