05b_in-mem-data.qmd

---
title: "Working Efficiently with Data"
---

In this section will focus on best practices for working efficiently with data, primarily with tabular data.

## Use appropriate data structures

To begin with, let's have a look at differences in performance of working with data in stored in different data structures.

### Matrix instead of data.frame

If all your tabular data is of a single data type (e.g. `numeric`, `logical`, `character` etc), it can be more efficient to store it as a matrix than as data.frame. That's because many functions can operate it on it with the confidence that all data will indeed be of a single data type instead of having to perform data type coercions or checks on whether the operation is possible.

Let's have a look at an example where we store the same data as a matrix and a data.frame. Our data is a large table with 10,000 rows and 150 columns.

```{r}
set.seed(1)
rows <- 10000
cols <- 150

data_mat <- matrix(rnorm(rows * cols, mean = 10), ncol = cols)
data_df <- as.data.frame(data_mat)
```

Let's now set up a `bench::press()` and test the performance of a number of function on the two data structures.

```{r}
bench::press(
    fn_name = c("rowSums", "rowMeans", "colSums", "colMeans", "sqrt"),
    {
        fn <- get(fn_name)
        bench::mark(
            df = fn(data_df),
            mat = fn(data_mat),
            check = FALSE
        )
    }
)
```

Matrices are clearly more performant especially on row wise operations. They are still faster on column wise operations by a decent margin as well as vectorised mathematical operations like `sqrt()` although less so.

### Single vs double precision floating point

Base R numeric types are either "double" which indicates double precision floating points or integer.

Package `float` enables storing numeric values as single precision (aka). Floats have half the precision of double precision data, for a **pretty obvious performance vs accuracy tradeoff**.

A matrix of floats should use about half as much memory as a matrix of doubles which can be really useful if you're dealing with data approaching memory limits:

```{r}
library(float)
data_fl_mat <- fl(data_mat)

pryr::object_size(data_mat)
pryr::object_size(data_fl_mat)
```

In addition many matrix routines will generally compute about twice as fast on them as well.

```{r}
bench::press(
    fn_name = c("rowSums", "colSums", "sqrt"),
    {
        fn <- get(fn_name)
        bench::mark(
            mat = fn(data_mat),
            fl_mat = fn(data_fl_mat),
            check = FALSE
        )
    }
)
```

By switching to single precision floating points, we see additional speed ups of row-wise operations although none for column-wise operations. We do however see a huge speed up of the vectorised calculation of `sqrt()`.

For more details on the routines available, consult the [`float` pkg documentation](https://cran.r-project.org/web/packages/float/readme/README.html).

::: callout-caution
**A note of caution:** The results of matrix routines on float data will not be as accurate, and are much more prone to roundoff error/mass cancellation issues. If your data is [well-conditioned](https://en.wikipedia.org/wiki/Condition_number), then using floats is "probably" fine for many applications. They can be an invaluable approach to consider when working with data that cannot but must fit into memory as double.
:::

### Efficient Indexing

Before moving on to data munging and more complex manipulating of data, let's briefly have at look at different approaches for indexing, i.e. the process of extracting specific elements of a data structure.

#### Indexing tabular data

Let's set up a very simple test, say we want to extract rows 10 to 15 from the 55th column of our example data.

Let's compare using a variety of base R approaches on both our matrix and data.frame. We'll also include the `dplyr` version of extracting the same values.

```{r}
#| message: false
library(dplyr)
```

```{r}
bench::mark(
    data_mat[10:15, 55],
    data_df[[55]][10:15],
    data_df[["V55"]][10:15],
    data_df[10:15, 55],
    data_df[10:15, "V55"],
    dplyr = {
    select(data_df, V55) %>%
        slice(10:15) %>%
        pull()
    }
)
```

-   Indexing matrices is by far the fastest, almost by an order of magnitude!

-   It can be more efficient to extract vectors from a data.frame and then subset those instead of indexing rows and columns in the data.frame directly.

-   Base R is much faster than `dplyr` for simple indexing.

#### Indexing lists

Similarly there is a variety of ways of indexing lists, some more efficient than others. Here I've just created a list where each element is an element of `letters` while each element's name in the corresponding capital letter

```{r}
letter_list <- setNames(letters, LETTERS) |>
    as.list()

head(letter_list)
```

Say we want to access the value in the fourth element, element `"D"`.

I've put together a number of approaches, ranging from using `purrr::pluck()` and piping the data (something I see quite often these days) to standard base indexing using in numeric indexing and indexing by name.

```{r}
bench::mark(
    magrittr_pipe = {
        letter_list %>%
        purrr::pluck("D")
    },
    base_r_pipe = {
        letter_list |>
        purrr::pluck("D")
    },
    purrr_no_pipe = {
        purrr::pluck(letter_list, "D") 
    },
    base_dollar_idx ={
        letter_list$D
    },
    base_chr_idx ={
        letter_list[["D"]]
    },
    base_int_idx ={
        letter_list[[4]]
    }
)
```

-   The fastest way to index a list is using base R and a numeric index or character name.

-   Dollar sign indexing is slower (and not as safe) because R looks for partial matches.

-   `purrr::pluck()` is orders of magnitude slower, especially when a pipe is thrown in there for good measure! If you're doing simple indexing, I would avoid `pluck()` all together.

Base R can be extremely efficient at indexing into data structures, especially matrices.

Again, here we are in the real of micro-optimisations, but if you're going to be running your code 1000s of times, these micro-optimisations soon add up.

# Efficient Data munging

In the real word, we're often dealing with mixed types of data that cannot be stored in a matrix and need to perform more complicated operations than summing rows or indexing.

So let's now turn to some of the most common data munging operations and compare and contrast the performance of a few of the most well known packages in use today to work with data.frames.

#### **`dplyr`**

`dplyr` is the flag ship package of the tidyverse, providing a consistent set of verb functions to help address the most common data manipulation challenges in a user friendly way.

##### **PROs**

-   well integrated collection of functions for data munging.

-   easy to read and interpret code even as a beginner.

-   reasoning about operations made easier by the use of pipes as well as doing away with the need for intermediate objects.

-   In addition to data frames/tibbles, dplyr makes working with other computational backends like databases and arrow tables accessible and efficient.

##### **CONs**

-   quite verbose and code can end up running across many lines.

-   can be (comparatively) slow.

##### Example

```{r}
mtcars %>% 
    filter(wt < 5) %>% 
    mutate(l100k = 235.21 / mpg) %>% # liters / 100 km
    group_by(cyl) %>% 
    summarise(l100k = mean(l100k))
```

#### **`data.table`**

Provides a high-performance version of [base R](https://www.r-project.org/about.html)'s `data.frame` with syntax and feature enhancements for ease of use, convenience and programming speed. It has it's own compact syntax that feels like a blend of base R and some dplyr concepts (e.g. the `by` argument for grouping operations by syntax.

At it's most basic, data.table syntax can be summarised as

>     DT[i, j, by]

where `i` is used for filtering or reordering rows, `j` is used for manipulating and selecting columns and `by` is used for grouping operations.

Instead of piping `data.table` uses the concept of chaining, where subsequent expressions are performed creating a chain of operations through the construct `DT[...][...][...] etc`.

##### **PROs**

-   syntax is very compact

-   generally faster for many operation, especially as the sizes of datasets grow

-   operations that modify data in place improve memory efficiency and can also boost performance

-   extremely fast functionality for reading in data through function `fread`.

##### **CONs**

-   Syntax can be confusing to understand and work with without familiarity with the package especially when chaining multiple operations

##### Example

```{r}
library(data.table)
mtcars_dt <- as.data.table(mtcars)
mtcars_dt[wt < 5, `:=`(l100k = 235.21/mpg)][, .(l100k = mean(l100k)), 
    keyby = .(cyl)]
```

#### **`dtplyr`**

dtplyr provides a [data.table](http://r-datatable.com/) backend for dplyr. The goal of `dtplyr` is to allow you to write dplyr code that is automatically translated to the equivalent, but usually much faster, data.table code. The current implementation focuses on lazy evaluation triggered by use of [`lazy_dt()`](https://dtplyr.tidyverse.org/reference/lazy_dt.html). This means that **no computation is performed until you explicitly request it with [`as.data.table()`](https://rdatatable.gitlab.io/data.table/reference/as.data.table.html), [`as.data.frame()`](https://rdrr.io/r/base/as.data.frame.html) or [`as_tibble()`](https://tibble.tidyverse.org/reference/as_tibble.html).**

##### **PROs**

-   provides ability to write dplyr code with often improved performance.

-   can be useful for learning how to translate `dplyr` code to `data.table` code.

##### **CONs**

-   does not always reach the performance of data.table and translations for some operations are yet to be available.

##### Example

First a `lazy_dt` needs to be created with `lazy_dt().` You can then use most dplyr functions as normal. Executing the code shows the `data.table` translation at the top section in `Call:`. This can be really useful for trying to learn `dplyr` syntax.

```{r}
library(dtplyr)
mtcars_dtp <- lazy_dt(mtcars)
mtcars_dtp %>% 
    filter(wt < 5) %>% 
    mutate(l100k = 235.21 / mpg) %>% # liters / 100 km
    group_by(cyl) %>% 
    summarise(l100k = mean(l100k))
```

The results of executing the above code cannot be accessed until one of `as.data.table()/as.data.frame()/as_tibble()` or even `collect()` is called at the end.

```{r}
mtcars_dtp %>% 
    filter(wt < 5) %>% 
    mutate(l100k = 235.21 / mpg) %>% # liters / 100 km
    group_by(cyl) %>% 
    summarise(l100k = mean(l100k)) %>%
    as_tibble()
```

## Benchmarking data munging operations

### Load data and create data structures for comparison

In this section we'll use the synthetic datasets created for this course. I'll be using the file with 10,000,000 but If you prefer to use a smaller one feel free to. Note though that, in general, the benefits of using `data.table` increase with the size of the dataset.

Let's go ahead and load our `parquet` data using `arrow::read_parquet()` which loads the data as a `tibble`.

```{r}
data_df <- arrow::read_parquet("data/synthpop_10000000.parquet")
```

We can have a look at the characteristics if our data using `skimr::skim()`.

*Note: this can take a lot of time to compute so feel free to skip this step.*

```{r}
skimr::skim(data_df)
```

Let's now create a `data.table` and `lazy_dt` from our data to run our benchmarks against.

```{r}
data_dt <- as.data.table(data_df)
data_dtp <- lazy_dt(data_dt)
```

### Basic Benchmarks

First, let's compare some basic operations on our data and include base R approaches.

#### Sub-setting

Let's start with some simple sub-setting.

##### Column sub-setting

First let's look at column sub-setting for the columns `"age"`, `"marital"`, `"income"` and `"sport"` and compare base R, `dplyr`, `dtplyr` and data.table approaches:

```{r}
bench::mark(
    "Base R" = {
        data_df[, c("age", "marital", "income", "sport")]
    },
    "dplyr" = {
        select(data_df, age, marital, income, sport)
    },
    "dtplyr" = {
        select(data_dtp, age, marital, income, sport) %>%
            as_tibble()
    },
    "data.table" = {
        data_dt[, .(age, marital, income, sport)]
    },
    check = FALSE)
```

We can see that in the case of column sub-setting, base R is actually highly performant, both in terms of memory and speed, almost 10x faster than `dplyr` which is the next fastest.

Surprisingly, `data.table` and `dtplyr` are both comparatively slow for simple column sub-setting operations.

##### Row filtering

Let's move on to comparing row filtering approaches. Let's filter for rows where values of `income` are not `NA` and `age` is greater than 30:

```{r}
bench::mark(
  "Base R" = {
    data_df[!is.na(data_df$income) & data_df$age > 30, ]
  },
  "dplyr" = {
    filter(data_df, 
                  !is.na(income) & age > 30) 
  },
  "dtplyr" = {
    filter(data_dtp, 
                  !is.na(income) & age > 30) %>%
          as_tibble()
  },
  "data.table" = {
    data_dt[!is.na(income) & age > 30, ]
  },
  check = FALSE)
```

In the case of row filtering, we find exactly the opposite! Both base R and `dplyr` perform similarly but are both significantly slower than `data.table` and `dtplyr`.

This is actually where `data.table` (and conversely `dtplyr`) really shine, in filtering rows.

::: callout-tip
Filtering using `data.table` can be speeded up even more using [keys](https://rdatatable.gitlab.io/data.table/articles/datatable-keys-fast-subset.html) and [secondary indices](https://rdatatable.gitlab.io/data.table/articles/datatable-secondary-indices-and-auto-indexing.html). So there's a lot of potential for further optimisation if you need to perform repeated filtering or aggregating on specific columns. Consult the `data.table` documentation for more details.
:::

##### Combined column and row sub-setting

Lastly, let's perform sub-setting involving both the row and column sub-setting we looked at previously.

```{r}

bench::mark(
  "Base R" = {
    data_df[!is.na(data_df$income) & data_df$age > 30, 
            c("age", "marital", "income", "sport")]
  },
  "dplyr" = {
    filter(data_df, 
                  !is.na(income) & age > 30) %>%
          select(age, marital, income, sport)
  },
  "dtplyr" = {
    filter(data_dtp, 
                  !is.na(income) & age > 30) %>%
          select(age, marital, income, sport) %>%
          as_tibble()
  },
  "data.table" = {
    data_dt[!is.na(income) & age > 30, 
            .(age, marital, income, sport)]
  },
  check = FALSE)

```

Overall, the computing requirements of filtering rows overshadows that of sub-setting columns so `data.table` emerge as the overall winner and the performance boost will increase in most cases with the size of the data set.

#### Ordering

Let's now have a look at performance of ordering. Let's order our data on the values of a single column, `income`.

In `data.table` there are a couple of approaches that can be used. The first is to use `order()` in `i` which creates a vector of indices indicating the order of the values in the column name passed to `order()` and effectively uses those indices to sub-set the rows in the correct order. This version orders `NA`s at the bottom as do all the other approaches.

A more efficient approach is to use `data.table`'s function `setorder()`. This version orders `NA`s at the top.

Because `setorder()` would modify `data_dt` in place, in one test we'll perform the ordering on a copy of `data_dt` using function `copy` to better reflect the behaviour of the other expressions.

We'll also test the speed of modifying in place though too. The modification in place behaviour of `data.table` poses challenges in a repeated testing environment, because, once the object is modified in place the first time the ordering is performed, subsequent runs do not reflect any ordering operation as the object is already ordered. To address this, I've turned memory profiling off, as this runs the code once to get the memory profile regardless of the number of test iterations, and then set the number of iterations to 1 so that each test is run only once.

```{r}
bench::mark(
  "Base R" = {
    data_df[order(data_df$income),]
  },
  "dplyr" = {
    arrange(data_df, income)
  },
  
  "dtplyr" = {
    arrange(data_dtp, income) %>%
          as_tibble()
  },
  "data.table_order" = {
    data_dt[order(income)]
  },
  "data.table_setorder_copy" = {
    setorder(copy(data_dt), income)
  },
  "data.table_setorder" = {
      setorder(data_dt, income)
  },
  iterations = 1,
  memory = FALSE,
  check = FALSE)
```

Base R, `dplyr` and ordering a `data.table` using `order()` come back as the slowest approaches. `setorder()` is faster, even on a copy of the object, with `dtplyr` coming up as marginally fastest.

Before moving on, let's reset `data_df` which we just modified.

```{r}
data_dt <- as.data.table(data_df)

```

#### Mutating

For our final basic test, let's have a look at mutating, i.e. creating a new column from calculation performed using values from another column in our dataset. For this example, we'll calculate the relative income compared to mean income across the whole population.

To compare similar behaviour and allow us to include a comparison to base R, we'll write our tests so that the original object is actually modified. We'll again turn off memory profiling and set the number of iterations again to ensure we're not re-modifying previously modified objects which could affect our results. Also to ensure our original data objects are not overwritten by the test, we perform the testing in a new and separate environment by using `bench::marks()`'s `env` argument. This however does not work for `data.table`s so we'll again need to reset `data_dt` once we're done.

```{r}
#| eval: false
bench::mark(
    "Base R" = {
        data_df$rel_income <- data_df$income/mean(data_df$income, na.rm = TRUE)
    },
    "dplyr" = {
        data_df <- mutate(data_df, rel_income = income/mean(income, na.rm = TRUE))
    },
    "dtplyr" = {
        data_dtp <- mutate(data_dtp, rel_income = income/mean(income, na.rm = TRUE)) %>%
            as_tibble()
    },
    "data.table" = {
        data_dt[, rel_income := income/mean(income, na.rm = TRUE)]
    },
  iterations = 1,
  memory = FALSE,
  check = FALSE,
  env = new.env())
```

```{r}
#| echo: false
bm <- bench::mark(
    "Base R" = {
        data_df$rel_income <- data_df$income/mean(data_df$income, na.rm = TRUE)
    },
    "dplyr" = {
        data_df <- mutate(data_df, rel_income = income/mean(income, na.rm = TRUE))
    },
    "dtplyr" = {
        data_dtp <- mutate(data_dtp, rel_income = income/mean(income, na.rm = TRUE)) %>%
            as_tibble()
    },
    "data.table" = {
        data_dt[, rel_income := income/mean(income, na.rm = TRUE)]
    },
  iterations = 1,
  memory = FALSE,
  check = FALSE,
  env = new.env())

bm
```

Here `data.table()` is the clear winner, over `r floor(unclass(bm$median[1]/bm$median[4]))` faster than base R and `r floor(unclass(bm$median[2]/bm$median[4]))` faster than `dplyr`. `dtplyr` is still fast but almost 2x slower than `data.table`.

Because we've modified `data_dt` again, let's go ahead and reset it before moving on.

```{r}
data_dt <- as.data.table(data_df)
```

### More complex examples

Now that we've looked at the isolated performance of different types of data munging, let's explore performance of more complex computations on our data. This also gives us an opportunity to explore `data.table` syntax a bit more and compare to `dplyr` syntax.

#### Example 1

In this example we'll combine filtering, selecting and arranging operations and this time we'll perform arranging over a larger number of columns:

```{r}
bench::mark(
    dplyr = {
        filter(data_df,
               age > 50L & age < 60L, 
               income < 300) %>%
            select(bmi, age, income, nociga, sex) %>%
            arrange(bmi, age, income, nociga, sex)
    },
    dtplyr = {
        filter(data_dtp,
               age > 50L & age < 60L, 
               income < 300) %>%
            select(bmi, age, income, nociga, sex) %>%
            arrange(bmi, age, income, nociga, sex) %>%
            as_tibble()
        },
    data.table = {
        data_dt[age > 50L & age < 60L & income < 300, 
                .(bmi, age, income, nociga, sex)][
                    order(bmi, age, income, nociga, sex)
                    ]
    },
    iterations = 5,
    check = FALSE
)

```

`data.table` is fastest with `dtplyr` close behind, yet the differences are not as big as some of the order of magnitude differences we've seen in other examples.

#### Example 2

Let's explore some performance differences on aggregating across groups and calculating summary statistics. We'll start some example with some complex filtering, then group our results by marital status and then calculate min, max and mean income across each group.

```{r}
bench::mark(
        dplyr = {
            filter(data_df,
                   age > 65L,
                   sex == "MALE",
                   sport == TRUE,
                   !is.na(income),
                   !is.na(marital)) %>%
                group_by(marital) %>%
                summarise(min_income = min(income),
                          max_income = max(income),
                          mean_income = mean(income))
    },
    dtplyr = {
            filter(data_dtp,
                   age > 65L,
                   sex == "MALE",
                   sport == TRUE,
                   !is.na(income),
                   !is.na(marital)) %>%
                group_by(marital) %>%
                summarise(min_income = min(income),
                          max_income = max(income),
                          mean_income = mean(income)) %>%
            as_tibble()
    },
    data.table = {
        data_dt[ age > 65L &
                   sex == "MALE" &
                   sport == TRUE &
                   !is.na(income) &
                   !is.na(marital), 
                  .(min_income = min(income),
                          max_income = max(income),
                          mean_income = mean(income)),
                 keyby = .(marital)]
        },
    iterations = 5,
    memory = FALSE,
    check = FALSE
)
```

Here we're back to an order of magnitude difference in performance between `data.table/dtplyr` and `dplyr`, primarily due to the excellent performance of `data.table` on filtering.

#### Example 3

In our third example we'll add some mutating and creating a new column, `income_group`, which splits `income` into income brackets. We'll then calculate mean `bmi` across each income group.

```{r}
bench::mark(
    dplyr = {
        filter(data_df, !is.na(income)) %>%
            mutate(income_group = cut(income,
                                      breaks = seq(0, 16000, by = 1000),
                                      include.lowest = T,
                                      right = F)
                   
            ) %>%
            group_by(income_group) %>%
            summarise(bmi_mean = mean(bmi, na.rm = TRUE))
    },
    dtplyr = {
        filter(data_dtp, !is.na(income)) %>%
            mutate(income_group = cut(income,
                                      breaks = seq(0, 16000, by = 1000),
                                      include.lowest = T,
                                      right = F)
                   
            ) %>%
            group_by(income_group) %>%
            summarise(bmi_mean = mean(bmi, na.rm = TRUE)) %>%
            as_tibble()
    },
    data.table = {
        data_dt[!is.na(income)][, 
                                `:=`(income_group = cut(income, 
                                                        breaks = seq(0, 16000, by = 1000),
                                                        include.lowest = TRUE, 
                                                        right = FALSE)
                                )][, .(bmi_mean = mean(bmi, na.rm = TRUE)), 
                                   keyby = .(income_group)]
    },
    iterations = 5,
    check = FALSE
)
```

In this example, `data.table` and `dtplyr` are comparable and still much faster than that `dplyr`.

#### Example 4

For our final example, we'll again perform some initial filtering but this time aggregate across location which has a much higher number of groups than marital status. We'll then calculate mean number of cigarettes smoked (across smokers only) and the proportion of the population at a given location that are smokers.

```{r}
bench::mark(
    dplyr = {
        filter(data_df, 
               age < 30) %>%
            group_by(location) %>%
            summarise(nociga_mean = mean(nociga, na.rm = TRUE),
                      prop_smoke = sum(smoke)/n())
    },
    dtplyr = {
        filter(data_dtp, 
               age < 30) %>%
            group_by(location) %>%
            summarise(nociga_mean = mean(nociga, na.rm = TRUE),
                      prop_smoke = sum(smoke)/n()) %>%
            as_tibble()
    },
    data.table = {
        data_dt[age < 30][, .(nociga_mean = mean(nociga, na.rm = TRUE), 
                              prop_smoke = sum(smoke)/.N), 
                          keyby = .(location)]
    },
    iterations = 5,
    check = FALSE
)
```

Here, although `data.table` and `dtplyr` are again comparable and still faster than that `dplyr` the difference in perfromance is much smaller, indicating that when aggregating across many groups, `dplyr`'s relative performance appears to catch up.

::: callout-important
## Take Aways

-   Overall `data.table` performs better across most data munging tasks, often significantly so, with `dtplyr` being comparable or slightly slower but generally faster than `dplyr.`

-   `data.table/dtplyr` are especially fast on row filtering rows, less so on ordering data.

-   Base R is generally much slower for most data munging operations apart from selecting columns where it can actually be the fastest option by quite some margin.
:::

#### A side note on copying

One of the features that makes `data.table` very efficient is that it modifies the data in place. None of it's functions and operators create copies when manipulating a `data.table`. This behaviour also extends to using `dtplyr` on a `lazy_dt` object.

Let's have a look at a quick example. Let's perform some data munging on a `tibble`, `data.table` and `lazy_dt` version of the `mtcars` data while using `tracemem()` to keep track of any copies being made during the operations.

Let's filter for `wt < 5` and convert miles per gallon (`mpg`) into liters per 100 km in a new column called `l100k`.

```{r}
# Create data structures
mtcars_tbl <- as_tibble(mtcars)
mtcars_dt <- as.data.table(mtcars)
mtcars_dtp <- lazy_dt(mtcars)

# Tracemem objects
tracemem(mtcars_tbl)
tracemem(mtcars_dt)
tracemem(mtcars_dtp)
```

##### `tibble`

```{r}
# Munge tibble
mtcars_tbl %>% 
    filter(wt < 5) %>% 
    mutate(l100k = 235.21 / mpg) 
```

Performing the filtering and mutating on a tibble results internally in 3 copies being made! Surprisingly, this happens even when we are just filtering:

```{r}
mtcars_tbl %>% 
    filter(wt < 5)
```

##### `data.table`

When performing the same operation on a `data.table`, no copies are made:

```{r}
# Munge data.table
mtcars_dt[wt < 5, `:=`(l100k = 235.21/mpg)]
```

Indeed we don't even get the results printed out. That because the `data.table` was modified in place, without having to assign the result back to the original object. If we have a look at the object we can see that it now has the new `l100k` column.

```{r}
head(mtcars_dt)
```

`lazy_dt`

Let's have a look at what happens when using `dtplyr` on a `lazy_dt` object.

```{r}
mtcars_dtp %>% 
    filter(wt < 5) %>% 
    mutate(l100k = 235.21 / mpg) %>%
    as_tibble()
```

Interestingly we get similar behaviour to `data.table` with respect to coying, in that, no copies are made during the operation. However, it does not modify in place either. If we inspect the original object, there is no `l100k` column.

```{r}
mtcars_dtp
```

We would need to assign it back to `mtcars_dtp` if we wanted to replicate `data.table` behaviour.