# Is pandas now faster than data.table?

Here is the GitHub link to the most recent data.table benchmark.

The data.table benchmarks has not been updated since 2014. I heard somewhere that Pandas is now faster than data.table. Is this true? Has anyone done any benchmarks? I have never used Python before but would consider switching if pandas can beat data.table?

• That's a really bad reason to switch to python. Oct 25 '17 at 3:47
• @MatthewDrury how so? Data and the manipulation of it is 80% of my job. Only 20% is to fitting models and presentation. Why shouldn't I choose the one that gives me the results the quickest? Oct 25 '17 at 4:31
• Both python and R are established languages with huge ecosystems and communities. To reduce the choice to a single library is worshiping a single tree in a vast forest. Even so, efficiency is just a single concern among many even for a single library (how expressive is the interface, how does it connect to other library, how extensible is the codebase, how open are its developers). I would argue that the choice itself is a false dichotomy; both communities have a different focus, which lends the languages different strengths. Oct 25 '17 at 4:52
• you have a huge forest that is good for 20% of the work? so don't make a choice thst affecta 80% of your work? nothing stopping me from using panda to do data prep and then model in R python or Julia. i think my thinking is sound. if panda is faster than i should choose it as my main tool. Oct 25 '17 at 6:46
• Higher speed of data.table when selecting columns (50% gain) and higher speed of pandas when sorting rows (also a 50% gain) are most likely caused by data.table storing data by columns and pandas storing data by rows.
– qed
Jul 20 '18 at 2:52

Has anyone done any benchmarks?

Yes, the 2014's benchmark in question has turned into foundation for db-benchmark project. Initial step was to reproduce 2014's benchmark on recent version of software, then to make it a continuous benchmark, so it runs routinely and automatically upgrades software before each run. Over time many things have been added. Below is high level diff of the 2014's benchmark comparing to db-benchmark project.

New:

• continuous benchmark: runs routinely, upgrades software, re-run benchmarking script
• more software solutions: spark, python datatable, cuda dataframes, julia dataframes, clickhouse, dask
• more data cases
• two new smaller data sizes: 0.5GB (1e7 rows) and 5GB (1e8 rows)
• two more cardinality factors: unbalanced, heavily unbalanced
• sortedness
• data having NA
• advanced groupby questions
• median, sd
• range v1-v2: max(v1)-min(v2)
• top 2 rows: order(.); head(.,2)
• regression: cor(v1, v2)^2
• count and grouping by 6 columns
• benchmark task: join

Changes (see groupby2014 task for 2014 fully compliant benchmark script):

We are planning to add even more software solutions and benchmark tasks in future. Feedback is very welcome, feel invited to our issue tracker at https://github.com/h2oai/db-benchmark/issues.

Is pandas now faster than data.table?

According the our results pandas is not faster than data.table.

I am pasting medium size data 5GB (1e8 rows) groupby benchmark plot taken from the report at h2oai.github.io/db-benchmark as of 20210312. Consult the h2oai.github.io/db-benchmark#explore-more-data-cases for other data sizes (1e7, 1e9), data cases (cardinality, NAs, sorted), questions groups (advanced), or tasks (join).

For up-to-date timings please visit https://h2oai.github.io/db-benchmark.

– skan
Dec 16 '18 at 0:09
• @skan you can track status of that in github.com/h2oai/db-benchmark/issues/63 Dec 17 '18 at 5:17
• Good answer -- AFAICT the benchmarks you link were all run on the same VM? That is, under the same conditions, pandas and dask need over 128GB RAM for the 50GB table, while the others can perform under this constraint? If so it also reflects my experiences with pandas being very RAM inefficient for a lot of normal everyday stuff on moderate (~10GB) tables, and it's a much bigger issue most of the time than execution speed. (which is much closer and trades-off back and forth in any event depending on the specific workload.)
– jkf
Apr 13 '19 at 22:20
• @jkf yes, exactly. Machine is 128 GB memory because we are planning to test out of mem processing on 500 GB dataset (10e9 rows). Currently only spark and pydatatable will support that, also soon to be added clickhouse. Apr 20 '19 at 8:44
• @Arun timings here are not up to date anymore, DT is now 1.48s vs PD 5.18s for 1e8 rows Oct 4 '20 at 15:22

A colleague and I have conducted some preliminary studies on the performance differences between pandas and data.table. You can find the study (which was split into two parts) on our Blog (You can find part two here).

We figured that there are some tasks where pandas clearly outperforms data.table, but also cases in which data.table is much faster. You can check it out yourself and let us know what you think of the results.

EDIT:
If you don't want to read the blogs in detail, here is a short summary of our setup and our findings:

Setup

We compared pandas and data.table on 12 different simulated data sets on the following operations (so far), which we called scenarios.

• Data retrieval with a select-like operation
• Data filtering with a conditional select operation
• Data sort operations
• Data aggregation operations

The computations were performed on a machine with an Intel i7 2.2GHz with 4 physical cores, 16GB RAM and a SSD hard drive. Software Versions were OS X 10.13.3, Python 3.6.4 and R 3.4.2. The respective library versions used were 0.22 for pandas and 1.10.4-3 for data.table

Results in a nutshell

• data.tableseems to be faster when selecting columns (pandason average takes 50% more time)
• pandas is faster at filtering rows (roughly 50% on average)
• data.table seems to be considerably faster at sorting (pandas was sometimes 100 times slower)
• adding a new column appears faster with pandas
• aggregating results are completely mixed

Please note that I tried to simplify the results as much as possible to not bore you to death. For a more complete visualization read the studies. If you cannot access our webpage, please send me a message and I will forward you our content. You can find the code for the complete study on GitHub. If you have ideas how to improve our study, please shoot us an e-mail. You can find our contacts on GitHub.

• As you may have read from my answer, I already say that the results are mixed. Please clarify if I shall be more specific in my answer, potentially elaborating on some numbers. Apr 25 '18 at 18:23
• "Your access to this site has been limited." I can't seem to access the site on my phone nor on my work computer. Apr 25 '18 at 22:18
• I am sorry to read that. I have checked it myself on my phone and had no issues. Could have something to do with the country you try to connect from? Apr 26 '18 at 7:29
• "4 physical cores" = 8 logical cores. Also it helps to say which specific Intel i7 2.2GHz (which generation? which variant? -HQ?) and what cache size. And for the SSD, what read and write speeds?
– smci
Aug 2 '18 at 18:15
• How do they compare to Julia dataframes and JuliaDB?
– skan
Dec 16 '18 at 0:07

Nope, In fact if dataset size is sooooooo large that pandas crashes, you are basically stuck with dask, which sucks and you can't even do a simple groupby-sum. dplyr may not be fast, but it doesn't mess up.

I'm currently working on some little 2G dataset and a simple print(df.groupby(['INCLEVEL1'])["r"].sum())crashes the dask.

Didn't experience this error with dplyr.

So, if pandas can handle the dataset, I use pandas, if not, stick to R data table.

And yes, you can convert dask back to pandas dataframe with a simple df.compute() But it takes a fairly long time, so you might as well just wait patiently for pandas to load or datatable to read.

• Didn't know Dask was so bad. Perhaps you want to try R's disk.frame? github.com/xiaodaigh/disk.frame I am the author Mar 19 '19 at 3:46

I know this is an older post, but figured it may be worth mentioning - using feather (in R and in Python) allows operating on data frames / data tables and sharing those results through feather.

See feather's github page

• Segfaults for medium and big datasets Apr 16 '19 at 7:24