为什么2012年python中的pandas合并要比R中的data.table合并快？

Question

我最近遇到了python的pandas库，根据this benchmark的说法，它执行非常快的内存合并。它甚至比R（我选择的分析语言）中的data.table包还要快。

为什么pandas比data.table快得多？这是因为python比R具有固有的速度优势，还是有一些我不知道的折衷？有没有办法在data.table中执行内部和外部连接而不诉诸merge(X, Y, all=FALSE)和merge(X, Y, all=TRUE)？

这里是用于对各种包进行基准测试的R code和Python code。

Answer 1

pandas之所以更快，是因为我提出了一个更好的算法，该算法使用a fast hash table implementation - klib和C/Cython非常小心地实现，以避免不可矢量化部分的Python解释器开销。算法在我的演示文稿中有详细描述：A look inside pandas design and development。

与data.table的比较实际上有点有趣，因为R的data.table的整个要点是它包含各种列的预计算索引，以加速数据选择和合并等操作。在这种情况下（数据库连接），pandas的DataFrame不包含用于合并的预先计算的信息，可以说这是一个“冷”合并。如果我已经存储了连接键的分解版本，则连接速度会大大加快，因为分解是此算法的最大瓶颈。

我还要补充的是，pandas的data frame的内部设计比R的data.frame（这只是内部数组的列表）更适合这些操作。

Answer 2

当唯一字符串（levels）的数目很大时，Wes可能在data.table中发现了一个已知问题：10000。

Rprof()是否显示了在调用中花费的大部分时间sortedmatch(levels(i[[lc]]), levels(x[[rc]])？这并不是真正的连接本身（算法），而是一个初步步骤。

最近的努力已经开始允许键中的字符列，这将通过更紧密地与R自己的全局字符串哈希表集成来解决这个问题。一些基准测试结果已经由test.data.table()报告，但是该代码还没有连接起来，无法替换匹配的级别。

对于常规整数列，pandas合并是否比data.table快？这应该是一种将算法本身与因素问题隔离开来的方法。

此外，data.table还考虑到了时间序列合并。两个方面：i）多列有序键，如（id，datetime）ii）快速盛行连接（roll=TRUE）a.k.a.最后一次观察结转。

我需要一些时间来确认，因为这是我第一次看到与data.table的比较。

---

从2012年7月发布的data.table v1.8.0更新

• 内部函数sortedmatch（）已删除并替换为chmatch（） 将“factor”类型的列的i级与x级匹配时。这个 初步步骤是导致（已知的）显著减速 因子列的级别很大（例如10000）。恶化的 Wes McKinney演示的连接四个这样的柱的测试 （Python包Pandas的作者）。匹配一百万个字符串 例如，其中600000是唯一的，现在从16s减少到0.5s。

该版本中还包括：

• 现在在键中允许使用字符列，并且首选 因素。data.table（）和setkey（）不再将字符强制为 因素。因素仍然得到支持。执行FR#1493，FR#1224 和（部分）FR#951。

• 新函数chmatch（）和%chin%，match（）的更快版本 字符向量的%和%in%。R的内部字符串缓存是 已使用（未生成哈希表）。它们大约快4倍 比中示例上的match（）更重要？奇马奇。

截至2013年9月，CRAN上的data.table是v1.8.10，我们正在开发v1.9.0。NEWS实时更新。

---

但正如我最初写的，上面：

data.table has time series merge in mind. Two aspects to that: i) multi column ordered keys such as (id,datetime) ii) fast prevailing join (roll=TRUE) a.k.a. last observation carried forward.

因此，两个字符列的Pandas equi连接可能仍然比data.table快。因为它听起来像是对组合的两列进行哈希运算。table不会散列键，因为它考虑到了流行的有序连接。data.table中的“key”实际上就是排序顺序（类似于SQL中的聚集索引；也就是说，这就是数据在RAM中的排序方式）。例如，在列表中添加辅助键。

总而言之，这个特殊的两个字符列测试（包含10000个唯一字符串）所强调的明显的速度差异现在不应该那么糟糕，因为已知的问题已经解决了。

Answer 3

这个话题已经有两年的历史了，但当人们寻找熊猫和数据的比较时，似乎是一个很有可能登陆的地方

由于这两者都是随着时间的推移而发展的，我想在这里为感兴趣的用户发布一个相对较新的比较（从2014年开始）：https://github.com/Rdatatable/data.table/wiki/Benchmarks-:-Grouping

想知道Wes和/或Matt（顺便说一下，他们分别是Pandas和data.table的创建者，并且都在上面发表了评论）在这里是否也有新的消息要补充。

--更新--

jangorecki在下面发表的一条评论包含一个链接，我认为它非常有用：https://github.com/szilard/benchm-databases

此图描述了不同技术的聚合和连接操作的平均时间（更低=更快；上次更新的比较是在2016年9月）。对我来说真的很有教育意义。

回到问题上，R DT key和R DT引用了R的data.table的键控/非键控风格，并且在这个基准测试中比Python的Pandas（Py pandas）更快。