---
title: "butcher"
output: rmarkdown::html_vignette
vignette: >
%\VignetteIndexEntry{butcher}
%\VignetteEngine{knitr::rmarkdown}
%\VignetteEncoding{UTF-8}
---
```{r, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
comment = "#>",
eval = requireNamespace("parsnip", quietly = TRUE)
)
```
```{r setup}
library(butcher)
library(parsnip)
```
One of the benefits of working in R is the ease with which you can implement complex models and implement challenging data analysis pipelines. Take, for example, the parsnip package; with the installation of a few associated libraries and a few lines of code, you can fit something as sophisticated as a boosted tree:
```{r, eval = FALSE}
fitted_model <- boost_tree(mode = "regression") %>%
fit(mpg ~ ., data = mtcars)
```
Yet, while this code is compact, the underlying fitted result may not be. Since parsnip works as a wrapper for many modeling packages, its fitted model objects inherit the same properties as those that arise from the original modeling package. A straightforward example is the `lm()` function from the base `stats` package. Whether you leverage parsnip or not, you get the same result:
```{r}
parsnip_lm <- linear_reg() %>%
fit(mpg ~ ., data = mtcars)
parsnip_lm
```
Using just `lm()`:
```{r}
old_lm <- lm(mpg ~ ., data = mtcars)
old_lm
```
Let's say we take this familiar `old_lm` approach in building a custom in-house modeling pipeline. Such a pipeline might entail wrapping `lm()` in other function, but in doing so, we may end up carrying around some unnecessary junk.
```{r}
in_house_model <- function() {
some_junk_in_the_environment <- runif(1e6) # we didn't know about
lm(mpg ~ ., data = mtcars)
}
```
The linear model fit that exists in our custom modeling pipeline is then:
```{r}
library(lobstr)
obj_size(in_house_model())
```
But it is functionally the same as our `old_lm`, which only takes up:
```{r}
obj_size(old_lm)
```
Ideally, we want to avoid saving this new `in_house_model()` on disk, when we could have something like `old_lm` that takes up less memory. But what the heck is going on here? We can examine possible issues with a fitted model object using the butcher package:
```{r}
big_lm <- in_house_model()
weigh(big_lm, threshold = 0, units = "MB")
```
The problem here is in the `terms` component of `big_lm`. Because of how `lm()` is implemented in the base `stats` package (relying on intermediate forms of the data from `model.frame` and `model.matrix`) the **environment** in which the linear fit was created is carried along in the model output.
We can see this with the `env_print()` function from the rlang package:
```{r}
library(rlang)
env_print(big_lm$terms)
```
To avoid carrying possible junk around in our production pipeline, whether it be associated with an `lm()` model (or something more complex), we can leverage `axe_env()` from the butcher package:
```{r}
cleaned_lm <- axe_env(big_lm, verbose = TRUE)
```
Comparing it against our `old_lm`, we find:
```{r}
weigh(cleaned_lm, threshold = 0, units = "MB")
```
And now it takes the same memory on disk:
```{r}
weigh(old_lm, threshold = 0, units = "MB")
```
Axing the environment, however, is not the only functionality of butcher. This package provides five S3 generics that include:
- `axe_call()`: Remove the call object.
- `axe_ctrl()`: Remove the controls fixed for training.
- `axe_data()`: Remove the original data.
- `axe_env()`: Replace inherited environments with empty environments.
- `axe_fitted()`: Remove fitted values.
In our case here with `lm()`, if we are only interested in prediction as the end product of our modeling pipeline, we could free up a lot of memory if we execute all the possible axe functions at once. To do so, we simply run `butcher()`:
```{r}
butchered_lm <- butcher(big_lm)
predict(butchered_lm, mtcars[, 2:11])
```
Alternatively, we can pick and choose specific axe functions, removing only those parts of the model object that we are no longer interested in characterizing.
```{r}
butchered_lm <- big_lm %>%
axe_env() %>%
axe_fitted()
predict(butchered_lm, mtcars[, 2:11])
```
The butcher package provides tooling to axe parts of the fitted output that are no longer needed, without sacrificing much functionality from the original model object.