Jes*_*per 10 r data.table
速度似乎有所不同，具体取决于您如何指定要从 data.table: x[, .(var)]vs 中选择的列x[, c('var')]。其原因可能是完全显而易见的，但是在帮助页面.()，list()和c()符号似乎可以互换使用。我使用相当大的数据集，所以这对我来说有点重要:-)
示例（调用顺序不影响速度）：
x <- as.data.table(as.character(rnorm(20000000,1,0.5)))
setkey(x, V1)
tic(); x[, .(V1)]; toc()
25.08 sec elapsed
tic(); x[, c('V1')]; toc()
0.28 sec elapsed
tic(); x[, 1]; toc()
0.02 sec elapsed
> sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18362)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] tictoc_1.0 data.table_1.12.8
loaded via a namespace (and not attached):
[1] compiler_3.6.1 tools_3.6.1 lifecycle_0.2.0 rlang_0.4.6
您发现了一个错误（问题在此处提交）--data.table正在尝试确定 的输出是否[]已键入；为此，它正在运行一个内部is.sorted功能。这在一个巨大的独特字符串表上非常慢。
幸运的是，我们可以进行静态分析并意识到您的输出表实际上是键控的——没有子集，键列 ( V1) 没有变化。因此排序顺序不能更改，您的输出也将按V1.
此逻辑内置于PR 中以解决此问题——您可以使用 对其进行测试remotes::install_github('Rdatatable/data.table@fix_sorting_on_sorted')，但需要注意的是，这是该软件包的最新版本，或者您可以等到它合并到 master 或新版本发布到 CRAN。
与此同时，这里有一个解决方法：
setkey(x, NULL)
system.time(x[ , .(V1)])
# user system elapsed
# 0.120 0.087 0.213
当然，这会阻止以后的处理识别您的数据已排序及其效率......
在这种情况下（！仅在这种情况下 - 小心使用！！！） - 您自己确定数据已经按以下方式排序V1- 您可以立即恢复密钥：
setattr(x, 'sorted', 'V1')
更一般地有选择有间小的差异[，[[，$等[会往往是最慢的，因为我们做了很多“静态查询分析”，以帮助提高你的代码的效率，来与它性能上的开销，我们希望意志几乎每次都变小。任何时候这个成本都不小，它应该是一个错误。还有一些工作正在积极进行中尝试提供捷径来减少这种开销，例如参见这个 PR