3
data.table vs dplyr：一个人可以做得很好，另一个人不能做得不好吗？
总览 我相对熟悉data.table，而不是那么熟悉dplyr。我已经阅读了一些出现在SO上的dplyr插图和示例，到目前为止，我的结论是： data.table且dplyr速度可比，除非有很多（即> 10-100K）组，并且在某些其他情况下（请参见下面的基准） dplyr 具有更多可访问的语法 dplyr 抽象（或将）潜在的数据库交互 功能上有一些细微的差异（请参见下面的“示例/用法”） 我认为2.不太重要，因为我相当熟悉它data.table，尽管我知道这对新手和老手来说都是一个很大的因素。我想避免争论哪个更直观，因为从我已经熟悉的人的角度来看，这与我提出的具体问题无关data.table。我还想避免讨论“更直观”如何导致更快的分析（当然是正确的，但又不是我对此最感兴趣的内容）。 题 我想知道的是： 对于熟悉软件包的人来说，是否有分析任务更容易用一个或另一个软件包编写代码（即，要求的击键与要求的深奥程度的某种组合，每个击键都是一件好事）。 在一个程序包中，是否有比其他程序更有效地执行分析任务（即大于2倍）？ 最近的一个SO问题使我对这个问题进行了更多的思考，因为到那时为止，我认为dplyr提供的功能超出了我已经可以做得到的范围data.table。这是dplyr解决方案（Q末的数据）： dat %.% group_by(name, job) %.% filter(job != "Boss" | year == min(year)) %.% mutate(cumu_job2 = cumsum(job2)) 这比我尝试破解data.table解决方案要好得多。也就是说，好的data.table解决方案也相当不错（感谢Jean-Robert，Arun，并请注意，在这里，我赞成使用单一语句而不是严格的最佳解决方案）： setDT(dat)[, .SD[job != "Boss" | year == min(year)][, cumjob := cumsum(job2)], by=list(id, job) ] 后者的语法可能看起来很深奥，但是如果您习惯了data.table（例如，不使用一些更深奥的技巧），它实际上非常简单。 理想情况下，我希望看到的是一些很好的示例，它们的方式dplyr或data.table方法实质上更简洁，或性能更好。 例子 用法 …
758
r
data.table
dplyr