[解決済み] 2012年、なぜpythonのpandasマージはRのdata.tableマージより速かったのか？

質問

最近、私は パンダ によると、このライブラリは このベンチマーク は非常に高速なインメモリマージを実行します。 これは データテーブル パッケージで提供されています。

なぜ pandas よりもはるかに高速です。 data.table ? Python が R よりも本質的に速いという利点があるからでしょうか、それとも私が知らない何らかのトレードオフがあるのでしょうか？ で内側joinと外側joinを実行する方法はありますか？ data.table に頼ることなく merge(X, Y, all=FALSE) と merge(X, Y, all=TRUE) ?

以下は Rコード と Pythonコード 様々なパッケージのベンチマークに使用されます。

どのように解決するのですか？

での既知の問題を発見したようです。 data.table 一意な文字列の数が多い場合 ( レベル )が大きい。10,000.

はたして Rprof() は、通話に費やされた時間のほとんどを明らかにします。 sortedmatch(levels(i[[lc]]), levels(x[[rc]]) ? これは、本当は結合そのもの（アルゴリズム）ではなく、その前段階です。

最近の取り組みでは、キーに文字列を使えるようにすることで、R自身のグローバルな文字列ハッシュテーブルとより密接に統合することで、この問題を解決することができるはずです。いくつかのベンチマーク結果は、すでに test.data.table() しかし、このコードはまだレベル間のマッチングを置き換えるためにフックアップされていません。

pandas のマージの速さは data.table 通常の整数カラムの場合？ それは、アルゴリズムそのものと要因の問題を切り分ける方法であるはずです。

また data.table は 時系列マージ を念頭に置いています。それには2つの側面があります：i) マルチカラム オーダーメイド のようなキー (id,datetime) ii) 高速な優先結合 ( roll=TRUE )、すなわち、最後の観測が繰り越される。

との比較は初めて見たので、確認に時間が必要です。 data.table を提示した。

2012年7月リリース data.table v1.8.0からUPDATE。

• 内部関数 sortedmatch() を削除し、chmatch() に置き換えた。 型 'factor' の列で i レベルと x レベルをマッチングさせる場合。この この予備的なステップにより、(既知の)著しい速度低下が発生しました。 のレベルが大きい場合（例：>10,000）。で悪化しました。 このような4つの列を結合するテストは、Wes McKinneyによって実証されました。 (PythonパッケージPandasの作者)です。100万個の文字列をマッチングし、そのうち のうち60万個が一意である場合、例えば16秒から0.5秒に短縮されました。

また、そのリリースでは、:

• 文字列がキーに使用できるようになり、キーよりも優先されるようになりました。 data.table() と setkey() は、文字を強制的に変換しなくなりました。 係数になります。因数分解はまだサポートされています。FR#1493, FR#1224 を実装。 と(部分的に)FR#951を追加しました。

• 新しい関数 chmatch() と %chin% は、match() の高速版です。 および文字ベクトル用の %in% があります。Rの内部文字列キャッシュが を利用する（ハッシュテーブルを構築しない）。約4倍高速化 chmatchの例では、match()よりも優れています。

2013年9月現在、data.tableはv1.8.10がCRANにあり、v1.9.0に取り組んでいます。 ニュース はライブで更新されます。

しかし、元々書いたように、上記．

data.table があります。 時系列結合 を念頭に置いています。それには2つの側面があります：i) マルチカラム オーダーメイド (id,datetime)のようなキー ii) 高速な優先順位付け を結合する ( roll=TRUE )、すなわち、最後の観測が繰り越される。

ですから、2つの文字列のPandas equi joinは、おそらくまだdata.tableより速いでしょう。2つのカラムを結合したものをハッシュしているようですが、data.tableは順序付き結合を念頭に置いているので、キーをハッシュしているわけではありません。data.tableにおけるquot;key"は文字通りソート順です（SQLにおけるクラスタ化インデックスに似ています；つまり、RAM上のデータの並び方です）。リストにあるのは、例えばセカンダリキーを追加することです。

要約すると、1万を超えるユニークな文字列を含むこの2文字列のテストによって明らかになった速度の差は、既知の問題が修正されたため、今ではそれほどひどくないはずです。