Performance R中的执行效率与程序员效率

经典而精彩的Perl编程参考书中有一节，作者提供了一系列关于如何编写计算效率最高的Perl的建议，接着是一系列关于如何编写程序员效率最高的Perl的建议，接着是关于维护人员效率、porter效率、，而且用户效率高。这个建议通常是完全矛盾的。（例如，“使用全局变量”，“不使用全局变量”。）

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

关于R风格，有哪些有趣且有用的建议？什么样的实践可以最大限度地提高程序员的效率，以及解决其他效率概念的等效实践是什么？

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

---

执行效率更难通过法令实现。你可能不得不回到经验法则（“向量化”）以及分析。你可以指望的是，在循环中，任何重建数据的东西都会变慢，比如在向量中添加元素，如果做得很多的话

---

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

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.