The data.table benchmarks hasn't 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?

  • 7
    $\begingroup$ That's a really bad reason to switch to python. $\endgroup$ – Matthew Drury Oct 25 '17 at 3:47
  • 3
    $\begingroup$ @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? $\endgroup$ – xiaodai Oct 25 '17 at 4:31
  • 2
    $\begingroup$ 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. $\endgroup$ – Matthew Drury Oct 25 '17 at 4:52
  • 5
    $\begingroup$ 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. $\endgroup$ – xiaodai Oct 25 '17 at 6:46
  • 2
    $\begingroup$ 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. $\endgroup$ – qed Jul 20 '18 at 2:52

Has anyone done any benchmarks?

Yes, the benchmark you have linked in your question has been recently updated for recent version of data.table and pandas. Additionally other software has been added. You can find updated benchmark at https://h2oai.github.io/db-benchmark
Unfortunately it is scheduled on 125GB Memory machine (not 244GB as the original one). As a result pandas and dask are unable to make an attempt of groupby on 1e9 rows (50GB csv) data because they run out of memory when reading data. So for pandas vs data.table you have to look at 1e8 rows (5GB) data.

To not just link the content you are asking for I am pasting recent timings for those solutions.

please note that those timings are outdated
visit https://h2oai.github.io/db-benchmark for updated timings

| in_rows|question              | data.table| pandas|
|   1e+07|sum v1 by id1         |      0.140|  0.414|
|   1e+07|sum v1 by id1:id2     |      0.411|  1.171|
|   1e+07|sum v1 mean v3 by id3 |      0.574|  1.327|
|   1e+07|mean v1:v3 by id4     |      0.252|  0.189|
|   1e+07|sum v1:v3 by id6      |      0.595|  0.893|
|   1e+08|sum v1 by id1         |      1.551|  4.091|
|   1e+08|sum v1 by id1:id2     |      4.200| 11.557|
|   1e+08|sum v1 mean v3 by id3 |     10.634| 24.590|
|   1e+08|mean v1:v3 by id4     |      2.683|  2.133|
|   1e+08|sum v1:v3 by id6      |      6.963| 16.451|
|   1e+09|sum v1 by id1         |     15.063|     NA|
|   1e+09|sum v1 by id1:id2     |     44.240|     NA|
|   1e+09|sum v1 mean v3 by id3 |    157.430|     NA|
|   1e+09|mean v1:v3 by id4     |     26.855|     NA|
|   1e+09|sum v1:v3 by id6      |    120.376|     NA|

In 4 out of 5 questions data.table is faster, and we can see it scales better.
Just note this timings are as of now, where id1, id2 and id3 are character fields. Those will be changed soon to categorical DONE. Besides there are other factors that are likely to impact those timings in near future (like grouping in parallel DONE). We are also going to add separate benchmarks for data having NAs, and various cardinalities DONE.

Other tasks are coming to this continuous benchmarking project so if you are interested in join, sort, read and others be sure to check it later.
And of course you are welcome to provide feedback in project repo!

| improve this answer | |
  • 1
    $\begingroup$ What about JuliaDB? $\endgroup$ – skan Dec 16 '18 at 0:09
  • 1
    $\begingroup$ @skan you can track status of that in github.com/h2oai/db-benchmark/issues/63 $\endgroup$ – jangorecki Dec 17 '18 at 5:17
  • 1
    $\begingroup$ 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.) $\endgroup$ – jkf Apr 13 '19 at 22:20
  • $\begingroup$ @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. $\endgroup$ – jangorecki Apr 20 '19 at 8:44
  • $\begingroup$ @jangorecki that's an extremely useful benchmark. Big thanks for the effort. I'm a bit puzzled about dask not being to digest the 50GB dataset. Dask has the partition size as one of the parameters (e.g. blocksize in read_csv). Did you try to avoid calling compute() and dump output to disk to avoid assembling the whole output table in memory? $\endgroup$ – Mischa Lisovyi Apr 20 '19 at 13:23

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.

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


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.

| improve this answer | |
  • 1
    $\begingroup$ 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. $\endgroup$ – Tobias Krabel Apr 25 '18 at 18:23
  • 1
    $\begingroup$ "Your access to this site has been limited." I can't seem to access the site on my phone nor on my work computer. $\endgroup$ – xiaodai Apr 25 '18 at 22:18
  • 1
    $\begingroup$ 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? $\endgroup$ – Tobias Krabel Apr 26 '18 at 7:29
  • 1
    $\begingroup$ "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? $\endgroup$ – smci Aug 2 '18 at 18:15
  • $\begingroup$ How do they compare to Julia dataframes and JuliaDB? $\endgroup$ – 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.

| improve this answer | |

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

| improve this answer | |
  • $\begingroup$ Segfaults for medium and big datasets $\endgroup$ – jangorecki Apr 16 '19 at 7:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.