R中的执行效率与程序员效率答案

【问题标题】：Execution Efficiency vs Programmer Efficiency in RR中的执行效率与程序员效率
【发布时间】：2023-03-03 09:24:21
【问题描述】：

经典而精彩的编程 Perl 参考书有一个部分，其中作者提供了有关如何编写最大限度地计算效率的 Perl 的建议列表，然后是有关如何编写的建议列表编写最大限度地程序员效率的 Perl，然后提供更多关于维护者效率、搬运工效率和用户效率的建议.建议通常是完全矛盾的。（例如，“使用全局变量”、“不要使用全局变量”。）

我在将一些“程序员高效”的 R 代码转换为“计算和维护高效”的代码时想到了这一点。

在这些方面有哪些关于 R 风格的有趣且有用的技巧？哪些做法可以最大限度地提高程序员的效率，以及解决其他效率概念的等效做法是什么？

【问题讨论】：

请记住，用户只关心应用程序的运行速度，而不是构建或维护它的速度，这似乎在过去几年中消失了，因为人们似乎认为程序员的效率胜过一切。相信我，它对用户没有影响。如果建议相互矛盾，请选择最有可能生成高效执行代码的建议，而不是最快编写的建议。
@HLGEM：用户还关心如何快速获得应用程序，以及他们的成本，以及有时可以多快将其修改为他们想要的内容。对于大多数应用程序来说，计算效率低下是无关紧要的。即使对于 R 类型的应用程序，计算能力的增长速度也远远快于程序员的生产力，因此平衡点越来越转向重视程序员的生产力。
我认为@HLGEM 的评论非常适合通用且受众广泛的桌面或网络应用程序。然而，用 R 编写的大部分内容都是特定领域的，并用作分析师工作台的一部分。我怀疑这种不同的用例从根本上改变了边际价值的计算。
@JD：对于大多数桌面和 Web 应用程序来说，计算效率并不那么重要。应用程序的性能通常会受到其他因素的限制。当然也有例外，但为了最大计算效率而进行编程通常是错误的做法。另一方面，R 通常用于计算效率很重要的数字目的。正如您所指出的，R 程序往往更加专业化，这也是事实，因此编程时间不能像收缩包装产品那样摊销。权衡是相似的，但进入它们的因素是不同的。

标签： performance r

【解决方案1】：

我认为样式指南（如前所述 SO）有助于提高程序员的效率。 R Core 似乎同意提供一些提示（以及用于一致缩进的 Emacs 参数）。

执行效率更难通过法令来实现。您可能不得不退回到经验法则（“矢量化”）以及分析。

【讨论】：

【解决方案2】：

你可以指望慢的是在循环中重建数据的任何事情，比如将元素附加到向量，如果它做了很多。

【讨论】：

【解决方案3】：

Programmer efficient                 |   Computationally efficient
                                     |
Write everything in R                |   Call C/Fortran routines
Reuse code                           |   Custom create everything 
  (functions not scripts,            |
  packages not individual functions) |
Use high level functions             |   Use low-level functions
Write things that work               |   Write it, profile it, optimise it.
                                     |     Repeat ad infinitum.

【讨论】：

希望看到更多这样的例子，尤其是更多细节！