我阅读了文章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 <喜欢的另一个原因。
感谢Matt Dowle等人
答案 0 :(得分：3)
感谢您的链接和赞誉。非常有趣的阅读。对我来说真正令人印象深刻的三点（在许多很酷的事情中）是：
将数据库嵌入到R /统计环境中（与规范相反）。
将两个系统置于同一地址空间。
从原始类型转换为SEXP而无需副本（/额外内存）。
虽然这些需要修改源。
在与data.table进行比较时，这里有一些问题：
他们与超过一年的v1.8.10进行比较。从那以后，data.table已经发展了很多。
更快且缓存高效的基于MSD的基数排序（对于整数，双精度，字符，整数64）。由于data.table使用排序来查找组索引以执行聚合，连接以及几乎所有其他操作，这意味着现在几乎所有操作都要快得多。
实施GForce以避免花费在评估每个组的j表达式上花费的时间，这使得对这些功能进行adhoc分组的速度更快。
实施了许多错误修复和功能 - 内存泄漏修复，通过避免不必要的副本等提高内存效率。Check news。
更快的子集化（使用本机实现），更快的二进制搜索（因此更快的连接和子集），以及最近的自动索引等。
还不清楚他们使用了什么编译器优化。
要想了解自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处理器上，请参阅链接中的详细规格），其中只有500个组聚合10GB数据需要大约18分钟基准（在3.4Ghz处理器上）。
他们没有在文章中谈论他们机器的缓存大小，数据维度，要分组的列数等等。（或者我错过了从文本中读取它）。
此后已经有一些性能修复。一旦this FR得到处理，预测将变得更快。重新运行此基准测试（可能还有更多测试）会很有趣，尽管我似乎无法在他们的文章中找到源代码的链接。
但又一次非常好的阅读。