164

私は最近、python 用のpandasライブラリに出会いました。これは、このベンチマークによると、非常に高速なインメモリ マージを実行します。R (分析用に選択した言語)のdata.tableパッケージよりもさらに高速です。

pandasよりもはるかに速いのはなぜdata.tableですか? それは、Python が R よりも優れている固有の速度の利点によるものですか、それとも私が気付いていないトレードオフがありますか? anddata.tableに頼らずに内部結合と外部結合を実行する方法はありますか?merge(X, Y, all=FALSE)merge(X, Y, all=TRUE)

比較

さまざまなパッケージのベンチマークに使用されたR コードとPython コードを次に示します。

4

4 に答える 4

191

pandas が高速な理由は、ベクトル化できない部分の Python インタープリターのオーバーヘッドを回避するために、高速ハッシュ テーブル実装 (klibおよび C/ Cython ) を使用して非常に慎重に実装された、より優れたアルゴリズムを思いついたからです。このアルゴリズムは、私のプレゼンテーションで詳しく説明されています: A look inside pandas design and development .

R の要点は、データの選択やマージなどの操作を高速化するために、さまざまな列の事前に計算されたインデックスが含まれていることであるため、との比較data.tableは実際には少し興味深いものです。この場合 (データベース結合) の pandas の DataFrame には、マージに使用される事前計算された情報が含まれていないため、いわば「コールド」マージです。結合キーの因数分解されたバージョンを保存した場合、結合は大幅に高速になります。因数分解がこのアルゴリズムの最大のボトルネックであるためです。data.table

また、pandas の DataFrame の内部設計は、R の data.frame (内部では単なる配列のリスト) よりも、これらの種類の操作にはるかに適していることも付け加えておきます。

于 2012-01-24T19:17:34.530 に答える
124

Wes はdata.table、一意の文字列 ( level ) の数が多い場合 ( 10,000 ) で既知の問題を発見したようです。

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

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

data.tableパンダのマージは、通常の整数列よりも高速ですか? これは、アルゴリズム自体と要因の問題を分離する方法である必要があります。

また、時系列のマージを念頭に置いていますdata.table。これには 2 つの側面があります。i) (id,datetime) などの複数列の順序付きキー ii) 高速結合 ( ) 別名、最後の観測が繰り越されます。roll=TRUE

data.table提示されたものとの比較を初めて見たので、確認するのに少し時間が必要です.

2012 年 7 月にリリースされた data.table v1.8.0 からの更新

  • タイプ「factor」の列の i レベルを x レベルに一致させる場合、内部関数 sortedmatch() が削除され、chmatch() に置き換えられました。因子列のレベル数が多い場合 (例: >10,000)、この準備段階により (既知の) 大幅な速度低下が発生していました。Wes McKinney (Python パッケージ Pandas の作成者) によって実証されたように、そのような 4 つの列を結合するテストで悪化しました。たとえば、100 万個の文字列のうち 600,000 個が一意である文字列の照合は、16 秒から 0.5 秒に短縮されました。

そのリリースにもありました：

  • 文字列がキーで許可されるようになり、factor よりも優先されます。data.table() と setkey() はもはや文字を因数分解しません。因子は引き続きサポートされます。FR#1493、FR#1224、および (部分的に) FR#951 を実装します。

  • 新しい関数 chmatch() および %chin%、文字ベクトル用の match() および %in% の高速バージョン。R の内部文字列キャッシュが使用されます (ハッシュ テーブルは作成されません)。?chmatch の例の match() よりも約 4 倍高速です。

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

しかし、私が最初に書いたように、上記：

data.table時系列のマージを念頭に置いています。これには 2 つの側面があります。i) (id,datetime) などの複数列の順序付きキー ii) 高速結合 ( roll=TRUE) 別名、最後の観測が繰り越されます。

したがって、2 つの文字列の Pandas 等結合は、おそらく data.table よりも高速です。結合された2つの列をハッシュしているように聞こえるので。data.table は、一般的な順序付き結合を念頭に置いているため、キーをハッシュしません。data.table の「キー」は、文字どおりソート順です (SQL のクラスター化インデックスに似ています。つまり、データが RAM で順序付けられる方法です)。リストには、たとえば、二次キーを追加することです。

要約すると、既知の問題が修正されているため、10,000 を超える一意の文字列を使用したこの特定の 2 文字列のテストによって強調された明白な速度の違いは、それほど悪くはないはずです。

于 2012-01-25T04:42:42.983 に答える