我读了这篇文章http://hannes.muehleisen.org/ssdbm2014-r-embedded-monetdb-cr.pdf很高兴看到 data.table 表现非常好。然而，令我惊讶的是，对于较大的文档(1GB 和 10GB)，选择、选择/投影和分组是如此之慢。我认为 data.table 很棒，而且令人惊讶的是，对于较大的数据集，它的速度要慢 5 倍到 10 倍。
我知道我不应该在微观基准测试上投入太多精力，而且我也没有这样做。事实上，读完这篇文章后，我更加确信使用 data.table 是有益的，因为它的语法一致且简单。我不仅关心原始性能。我问这个问题是因为 data.table 作者有兴趣研究这些问题，并且非常擅长解释为什么(或为什么不) data.table 如此执行。这是我喜欢喜欢使用 data.table 的另一个原因。
感谢马特·道尔等人。
最佳答案
感谢您的链接和赞扬。非常有趣的阅读。对我来说真正令人印象深刻的三点(在许多很酷的事情中)是:
将数据库嵌入到 R/统计环境中(与规范相反)。
将两个系统置于同一地址空间下。
从原始类型转换为 SEXP，无需复制(/额外内存)。
尽管这些需要对源代码进行修改。
与 data.table 进行比较，但这里有一些问题:
他们与一年多前的 v1.8.10 进行比较。从那时起，data.table 已经发展了很多。
更快且高效缓存的基于 MSD 的基数排序(适用于整数、 double 、字符、integer64)。由于 data.table 使用排序来查找组索引以执行聚合、连接和几乎所有其他操作，这意味着现在几乎所有操作都快得多。
实现 GForce 以避免花费时间评估每个组的 j 表达式，这使得使用这些函数进行临时分组更快。
许多错误修复和功能实现 - 内存泄漏修复，通过避免不必要的复制来提高内存效率等。 Check news .
更快的子集设置(使用 native 实现)、更快的二分搜索(因此更快的联接和子集)以及最近的自动索引等。
此外，还不清楚他们使用了哪些编译器优化。
要了解自 1.8.10 以来的加速情况，请查看 this recent benchmark由马特.
# data.table 1.9.2 50GB 10,000 groups < 1 minute (from Matt's benchmark)
# data.table 1.8.10 10GB 500 groups ~ 18 minutes! (from their article)
使用 data.table 将超过 50GB 的数据分组为 10,000 个组只需不到一分钟(在 2.5Ghz 处理器上，请参阅链接中的详细规范)，而将 10GB 的数据聚合为仅 500 个组大约需要 18 分钟基准测试(在 3.4Ghz 处理器上)。
他们没有在文章中谈论他们机器的缓存大小、数据维度、分组依据的列数等。(或者我错过了从文本中阅读它)。
从那时起，已经有一些性能修复。一次 this FR 投影将会变得更快受到照顾。尽管我似乎在他们的文章中找不到源代码的链接，但重新运行此基准测试(也许还有更多测试)会很有趣。
但又是一本非常好的读物。
关于r - 大型数据集中的选择/投影/分组，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27510407/