Question

I recently came across the pandas library for python, which according to this benchmark performs very fast in-memory merges. It’s even faster than the data.table package in R (my language of choice for analysis).

Why is pandas so much faster than data.table? Is it because of an inherent speed advantage python has over R, or is there some tradeoff I’m not aware of? Is there a way to perform inner and outer joins in data.table without resorting to merge(X, Y, all=FALSE) and merge(X, Y, all=TRUE)?

Here’s the R code and the Python code used to benchmark the various packages.

Answer 1

It looks like Wes may have discovered a known issue in data.table when the number of unique strings (levels) is large: 10,000.

Does Rprof() reveal most of the time spent in the call sortedmatch(levels(i[[lc]]), levels(x[[rc]])? This isn’t really the join itself (the algorithm), but a preliminary step.

Recent efforts have gone into allowing character columns in keys, which should resolve that issue by integrating more closely with R’s own global string hash table. Some benchmark results are already reported by test.data.table() but that code isn’t hooked up yet to replace the levels to levels match.

Are pandas merges faster than data.table for regular integer columns? That should be a way to isolate the algorithm itself vs factor issues.

Also, 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.

I’ll need some time to confirm as it’s the first I’ve seen of the comparison to data.table as presented.

---

UPDATE from data.table v1.8.0 released July 2012

• Internal function sortedmatch() removed and replaced with chmatch()
  when matching i levels to x levels for columns of type ‘factor’. This
  preliminary step was causing a (known) significant slowdown when the number
  of levels of a factor column was large (e.g. >10,000). Exacerbated in
  tests of joining four such columns, as demonstrated by Wes McKinney
  (author of Python package Pandas). Matching 1 million strings of which
  of which 600,000 are unique is now reduced from 16s to 0.5s, for example.

also in that release was :

• character columns are now allowed in keys and are preferred to
  factor. data.table() and setkey() no longer coerce character to
  factor. Factors are still supported. Implements FR#1493, FR#1224
  and (partially) FR#951.

• New functions chmatch() and %chin%, faster versions of match()
  and %in% for character vectors. R’s internal string cache is
  utilised (no hash table is built). They are about 4 times faster
  than match() on the example in ?chmatch.

As of Sep 2013 data.table is v1.8.10 on CRAN and we’re working on v1.9.0. NEWS is updated live.

---

But as I wrote originally, above :

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.

So the Pandas equi join of two character columns is probably still faster than data.table. Since it sounds like it hashes the combined two columns. data.table doesn’t hash the key because it has prevailing ordered joins in mind. A “key” in data.table is literally just the sort order (similar to a clustered index in SQL; i.e., that’s how the data is ordered in RAM). On the list is to add secondary keys, for example.

In summary, the glaring speed difference highlighted by this particular two-character-column test with over 10,000 unique strings shouldn’t be as bad now, since the known problem has been fixed.