June 22, 2019

Comparing fread, readr’s readcsv and base R. The data.table package is a bit lesser known in the R community, but if people know it, it is most likely for its speed when working with data tables themselves within R. Related Post: 101 R data.table Exercises. How to install data.table package. Installing data.table package is no different from other R packages. Its recommended to run install.packages to get the latest version on the CRAN repository. However, if you want to use the latest development version, you can get it from github as well.

Recently I was involved in a task that included reading and writing quite large amounts of data, totaling more than 1 TB worth of csvs without the standard big data infrastructure. After trying multiple approaches, the one that made this possible was using data.table’s reading and writing facilities - fread() and fwrite().

This motivated me to look at benchmarking data.table’s fread() and how it compares to other packages such as tidyverse’s readr and base R for reading tabular data from text files such as csvs.

Comparing fread, readr’s read_csv and base R

The data.table package is a bit lesser known in the R community, but if people know it, it is most likely for its speed when working with data tables themselves within R. The package however also provides functions for efficient reading and writing of tabular data from and into text files - fread() for fast reading and fwrite() for fast writing.

Another underrated property of the fread() apart from speed however is memory efficiency, which can be crucial if we need to read in a lot of data without big data infrastructure.

The benchmarked data

As the data for this quick benchmark, we used the Airline on-time performance data from for years 2000 to 2008. This simple code chunk can be used to retrieve and extract the data. The download size is 868 MB in bz2 files. The extracted size is 5.34 GB in csv files and when combined translates to a data frame with some 59 million rows and 29 columns. This is quite limited due to the specs of the machine used, but enough to show significant differences between packages.

Base R code to be benchmarked

Loading csv data from multiple files into a single data frame with base R is very simple:

data.table `fread` code to be benchmarked

For data.table, we use rbindlist() for row binding instead of do.call(rbind, ...) and fread() for reading:

`readr::read_csv` code to be benchmarked

The script for readr’s read_csv is also simple, with the small caveat that we need to predefine the column types, as rbind_rows does not like to coerce the data. Doing things the tidyverse way, we also use purrr::map_dfr() to for row binding and readr::read_csv() for reading:

The benchmarking method

A simple bash script was used to measure the maximum memory needed (Maximum resident set size to be precise) and to time the run of the script 10 times:

The results speak for themselves. Not only was fread() almost 2.5 times faster than readr’s functionality in reading and binding the data, but perhaps even more importantly, the maximum used memory was only 15.25 GB, compared to readr’s 27 GB. Interestingly, even though very slow, base R also spent less memory than the tidyverse suite.

For larger data sets, data.table’s efficiency can save not only very significant amounts of time, but also needed memory, which can have important implications with regards to the cost of the hardware needed for processing.

method	max. memory	avg. time
`utils::read.csv` + `base::rbind`	21.70 GB	8.13 m
`readr::read_csv` + `purrr:map_dfr`	27.02 GB	3.43 m
`data.table::fread` + `rbindlist`	15.25 GB	1.40 m

And it gets better than that. Consider a scenario where we need to read the data, subset or split into groups and compute on the processed data. The classic approach would be to load the data from files into R as seen above and then do the data processing.

For scenarios like these, fread() provides an ever more powerful facility - the cmd argument with a shell command that pre-processes the file(s). If we want to filter our data used above to only look at flights operated by American Airlines the classic approach would be to read the data in and filter. With fread() we can, however, use grep first and only have fread() process output of that command:

Looking at our benchmarks, this approach only cost us 1.68GB of memory and about 24 seconds of runtime on average:

method	max. memory	avg. time
`data.table::fread` from `grep`	1.68 GB	0.40 m

The above is of course only the beginning of potential optimizations. We could probably save a lot of time taking advantage of GNU parallel to process the files with grep much faster. The key here is the flexibility of inputs that fread can process, without splitting the inputs into multiple files and other maintenance-heavy pre-processing.

In a bigger data setting, this can have a significant impact on the cost of a data science project and even investments in big data infrastructure, engineers and maintenance related to managing such a project.

Did you find this post helpful or interesting? Help others find it by sharing:

A reviewer asked me to report detailed running times for all (so many ) performed computations in one of my papers, and so I spent a Saturday morning figuring out my favorite way to benchmark R code. This is a quick summary of the options I found to be available.

A quick online search revealed at least three R packages for benchmarking R code (rbenchmark, microbenchmark, and tictoc). Additionally, base R provides at least two methods to measure the running time of R code (Sys.time and system.time). In the following I briefly go through the syntax of using each of the five option, and present my conclusions at the end.

1. Using “Sys.time”

The run time of a chunk of code can be measured by taking the difference between the time at the start and at the end of the code chunk. Simple yet flexible .

2. Library “tictoc”

The functions tic and toc are used in the same manner for benchmarking as the just demonstrated Sys.time. However tictoc adds a lot more convenience to the whole.

The most recent development version of tictoc can be installed from github:

One can time a single code chunk:

Or nest multiple timers:

3. Using “system.time”

One can time the evaluation of an R expression using system.time. For example, we can use it to measure the execution time of the function sleep_for_a_minute (defined above) as follows.

But what exactly are the reported times user, system, and elapsed?

Well, clearly elapsed is the wall clock time taken to execute the function sleep_for_a_minute, plus some benchmarking code wrapping it (that’s why it took slightly more than a minute to run I guess).

As for user and system times, William Dunlap has posted a great explanation to the r-help mailing list:

“User CPU time” gives the CPU time spent by the current process (i.e., the current R session) and “system CPU time” gives the CPU time spent by the kernel (the operating system) on behalf of the current process. The operating system is used for things like opening files, doing input or output, starting other processes, and looking at the system clock: operations that involve resources that many processes must share. Different operating systems will have different things done

Install Fread In R