Improving serialization of ggplot2-objects

[koefoeden]

Hi! First of all, thanks for maintaining an amazing tool! I'm wondering if the maintainers would re-consider their stance on improving how serialization of ggplot2-objects are handled. Currently, as described in multiple old issues (#3619, #3994, #4056), serialized ggplot-objects retain any (potentially large) objects that were present during the "plot build process " - see below for another minimal reprex:

f <- function(create_large_object = FALSE) {
  if (create_large_object) {
    object_in_env <- rnorm(1e6)
  }

  p <- ggplot(cars) +
    geom_point(aes(speed, dist))

  path <- tempfile(fileext = ".rds")
  saveRDS(p, path)
  (file.info(path)$size) / 1024^2
}

cat("without large object: ", f(FALSE), "MB\n") # returns ~1 MB
cat("with large object: ", f(TRUE), "MB\n") # returns ~8 MB

I think this behavior is quite unexpected, and is likely resulting in many frustrations - especially because this behavior (and the fact that serialization is not recommended) is not well documented. Furthermore, I argue that, in contrast to previous opinions by the maintainers, there is a lot of value in being able to (unproblematically) serialize ggplots. As an example, serialization enables a structured and "tiered" analysis process, where initial plots during an explanatory phase (saved potentially both as image files and ggplot-objects) can be re-labelled, combined and/or re-formatted using the regular, powerful ggplot semantics when it's time for publication (or a similar goal). This is especially true when using ggplots in data analysis pipelines, facilitated by "targets" or similar frameworks, where serialization is used heavily, and where concerns of reproducibility and ggplot2-version incompatibility are naturally handled.

Furthermore, I think the suggested alternatives, such as manipulating how the plotting is done (e.g. in it's own environment), is often not feasible, because the plots will be created by external packages outside of the user's control. Another suggested alternative is to re-create plots from scratch, but this of course introduces a whole host of other problems. I am a huge fan of how ggplot2 has become a standard of plotting in R, but I think it is a big limitation that you cannot use serialization to edit the plots yourself after-the-fact in these problematic cases.

I realize that I have no grasp on how challenging/problematic this is to revise - but I wonder if it might be possible to (at least) alleviate some of the most common and unexpected cases, such as the reprex above, where a totally irrelevant object is contaminating the serialized file.

Looking forward to hearing what you think!

[teunbrand]

Thanks for raising the discussion. Part of the reason for the retention of large objects is because the non-standard evaluation mechanisms (like aes()) take a snapshot of the environment.

f <- function(large = TRUE) {
  if (large) {
    larg_obj <- rnorm(1e6)
  }
  ggplot2::aes(x = foo)
}
lobstr::obj_size(f(large = FALSE))
#> 25.13 kB
lobstr::obj_size(f(large = TRUE))
#> 8.03 MB

^{Created on 2026-04-23 with reprex v2.1.1}

At the time users declare this, it isn't sure whether the foo variable in the example comes from the environment or the data. The environment snapshot is so that they can lookup the variable in the environment that they were created in, in case it wasn't in the data. Similarly the plot_env() keeps track of environment variables in case it needs to lookup the default scale, which people can override.

I've made attempts that went nowhere at removing the plot_env (#3994) and then we're still left with aes() and vars() that have similar behaviour. While I think there might be a small improvement here or there —for example we can not attach the environment if using the data pronoun like aes(x = .data$foo), or only attach the variable (not the entire environment) if defined like aes(x = .env$foo)— this doesn't come 'for free' for users who now have to be very delibrate with specifications.

These environment problems comes in addition to the reproducibility across versions.

[koefoeden]

What about some compromise like the approach implemented here, which might be able to catch some cases:
main...koefoeden:ggplot2:ggplot2-pr

Full disclosure: This was from a previous experiment where I managed to fix specifically the reprex case by letting GPT-5.4 iterate for a bit, since I know nothing of the ggplot2-internals. So it might be totally useless, but figured it might be worth sharing anyway. And here is the explanation by GPT (since again, I wouldn't understand the specifics of the changes myself, other than the approach of "first seeing if we can find all the the neeeded stuff in data" seems somewhat sensible )

The current working approach is narrower than "strip everything", but broad
enough to fix the repro:

1. Compact plot_env at plot creation time so it only keeps reachable
   scale_* functions needed for deferred scale lookup.
2. Compact mapping quosures when a mapping is a bare symbol that can be
   identified as a known data column at plot construction time.

For example, a mapping like aes(speed, dist) with known data columns no longer
needs the full caller environment, so those quosures can safely be rebuilt with
emptyenv().

The key safety property is that non-data symbols are left alone. This preserves
important behavior such as:

• mappings that intentionally resolve variables from the plot creation
  environment;
• delayed definition of environment variables before plot build;
• custom local scale_* overrides.

Remaining caveat

The current quosure compaction is intentionally conservative. It only strips
environments for bare-symbol mappings that are clearly data columns. More
complex expressions such as aes(log(speed)) or wrappers involving local
functions still retain their environments unless a stronger static analysis or a
later normalization pass is introduced.

[teunbrand]

Apologies for the directness, but I'm a 'no' on this approach. It is a partial but invasive solution to fix a flawed workflow. I think this advice still holds: #4056 (comment).

[koefoeden]

No need to apologize! Perhaps I'm being completely oblivious here, but I'm not sure how your linked comment actually adresses the issue. The plot is never serialized in the example (just the function), and if you run the code and serialize the plot, it does indeed generate a very large ggplot-object on disk.

Also, would you mind elaborating on how workflows using ggplot-serialization are necessarily flawed? Isn't a composed plot a meaningful "object" that is worth being able to save (in the proper, mutable format) - just like we can serialize and save almost all other data structures? Especially because external packages will often bundle the plotting together with the necessary pre-processing (despite perhaps not being an optimal practice). Please note that I think it's completely valid that there might not be a good fix given how ggplot2 was designed, but I would like to challenge the idea that serialization indicates a flawed workflow.

[clauswilke]

@koefoeden A composed plot object is basically just a recipe for how to take information from the current environment and turn it into an image. You can serialize it, but the cost is that you have to save (in the worst case scenario) a complete snapshot of the current environment and all the installed packages. This doesn't sound like a useful strategy to me. You're literally picking the worst possible point in the pipeline to serialize.

Capturing either the data before it goes into plotting or the generated output image is much better because these objects (input data or output image) are easily bounded and it's fairly intuitive and predictable how large they will be. (Though even there there are pitfalls: If you make a scatter plot of 2GB of data and you save it as a pdf you can end up with a file that is 2GB large because it contains the entire dataset, point for point.)

More generally, it bothers me to no end that there are so many 3rd-party packages out there that muddle together complex calculations and plotting. The correct way (IMHO) is always to do all the computation first, store the computed data in a data frame or custom object, and then use that for plotting. Here is an example of a package that gets this right: https://andrie.github.io/ggdendro/reference/dendro_data.html And here is an example of package that gets it terribly wrong: https://sachsmc.github.io/plotROC/reference/calc_auc.html (The only way to compute a key statistic is to extract it from a ggplot object.)

Honestly, I think that instead of writing code that awkwardly tries to prune the environments stored in a ggplot object, at the cost of potentially obscure and difficult-to-debug bugs, it would be much better to encourage people to write proper workflows and to submit bug reports and feature requests to packages that don't separate computation from plotting. Alternatively, if people absolutely insist on serializing ggplot objects, they have to accept the storage requirements that come with that.

I recently wrote a blogpost that is somewhat relevant here (in the sense that it emphasizes storing your data right before plotting): https://blog.genesmindsmachines.com/p/creating-reproducible-data-analysis

[koefoeden]

@clauswilke Thanks for the very detailed reply - this is exactly the kind of discussion I had hoped to generate.

I think I'm starting to understand your view now. My motivating example to bring up this issue was working with Seurat, a widely popular R-framework for analysis of single-cell data that comes with ~50 different kinds of convenient plotting functions. These functions take in a large data container (the Seurat object), and extracts the needed parts (potentially doing some light processing), and then generates a ggplot2-object. Specifically, I have set up a shareable (to be published) extensive targets-framework using Seurat to generate and serialize these plots (among other things), with the idea that users (including myself) could then programatically combine plots and tweak them for their own publication efforts. I.e. basically setting up an (tweakable) idealized, end-end-end reproducible analysis and publication framework for this kind of data.

I originally had not considered Seurat's approach of "data-subsetting within the plotting context" to be part of your "problematic workflow" designation, since no heavy, complex computation is going on - just quick subsetting. However, I realize that such data-subsetting might fit under your definition of "computation", and should therefore be separated from the plotting context itself. Is this the case?

If so, I fear that expecting community-wide separation of data-subsetting and the plotting itself is much more unrealistic than the seperation of "data-processing", which is often compute-intensive, and therefore lends itself more naturally to separation from the plotting context. I imagine that the entanglement of data-subsetting and plotting is quite ubiqitous throughout data-science, since it is arguably a convenient, efficient and intuitive workflow.

[koefoeden]

However, I concede that Seurat's passing around of large-data containers might be an extreme example, which is an inherently a flawed approach in itself, and which might not be too common (especially in combination of serializing plots).

[koefoeden]

Also, I realize what I'm perhaps expecting from ggplot2 is to encapsulate and store the result of the data-subsetting transformations that people have bundled up with their ggplot2 code (together with the plot specifications) - which might not be entirely fair. It just seems so close within reach, since this is ultimately what is actually being shown on the plot ;)

EDIT: On the other hand, I think it can be argued that data-subsetting is an inherent part of the plotting process, and is what also happens (implicitly) inside the ggplot2-code, when you choose which aesthetic-mappings to create. Which ultimately would be a nice to be able to checkpoint, together with the actual plot composition (disregarding the actual feasibility within ggplot2). Would appreciate to hear your thoughts on this (and whether I might simply just be rambling now).

[clauswilke]

@koefoeden It sounds to me like what you want to serialize in the Seurat case is the Seurat object. Is there a problem with that? Is it too large?

Again, it sounds reasonable to say "I just want to store the ggplot object with the subset data, for efficiency" but the correct mental model is that the ggplot object is just the instructions on how to subset the data, with the actual subsetting being executed when the plot is generated. (I know there's an additional step of actual subsetting here in the Seurat case, but still the mental model you should use is the one I describe.) In fact, that's the reason you can still modify the plot, add layers, change the theme, and so on.

I think this is just an unavoidable tradeoff: If you want to serialize at the stage of the recipe, you have to hold on to all the things that could potentially become ingredients when the cake is being baked. (Since this is Turing-complete code, you can't truly ever know what will be needed until you execute the code.) Alternatively, you can serialize at the stage of the baked cake, but then you can no longer add raisins to the batter right before baking.

[koefoeden]

@clauswilke Serializing the Seurat object is essentially what happened every time I tried to serialize the ggplots, and unfortunately, these objects are many gigabytes, since they contain the full transcriptomic and epigenetic profile of each individual cell - when I just wanted a serialized plot of a particular, small aspect of the data. But yes, I completely get your point - and the discussion helped me re-frame what ggplot2 is actually doing. However, my point is exactly that wishing for the functionality to be able to serialize that baked cake, fully accepting that we can no longer add more raisins (but perhaps re-organizing them a bit after on top, i.e. changing axis names), is not an indicator of an inherently flawed approach, but is in fact quite reasonable - as it also sounds like you agree with. However, whether that is at all possible or feasible in ggplot2 is of course a completely different discussion. I apologize if I was not clear enough on that point, and I might have mis-interpreted your critique of the serialization of plot objects to be more general (i.e. less ggplot2-specific) than it actually is.

[teunbrand]

One difference between ggplot2's and base R's approach to drawing plots is that base R directly jots down everything on the canvas. Once you've called plot(), your axis limits are fixed. Once you've drawn points, there is no way to change their color.

In ggplot2, in order to declare a point layer first, and afterwards a scale to change the colors of those very points, one needs to keep track of all the instructions received. Only once all instructions are recieved, then something can be comitted to the canvas. The way of tracking these instructions is through objects. The object-ness is a tool; it is an intermediate representation to solve a necessary evil.

I get the convenience through flexibility argument, having worked with single cell data myself. I too saved ggplot2 objects to disk before getting into all sorts of kerfuffles. Loading some extensions can sometimes change how ggplot2 objects are interpreted, making them fragile across sessions. The objects are not self-contained: they may capture unintended data. It weakens reproducibility. I remain convinced that it is fine to serialise either the ingredients and recipe or the cake, but not the hot oven that does the baking.

[EvaMaeRey]

Just reflecting on the plotROC example, there is something flow-y about myplot |> calc_auc(): we build a plot, tinker and refine it based on what we see, and based on those refinements we settle on (e.g. grouping), we do some calculation. I'd thought that calc_auc would rely on layer_data, but it looks like it goes much more into the internals. I did wonder if using layer_data() wouldn't be a way to grab and save the processed data from the plot, so still using all the nice interactivity and visual feedback that ggplot2/seurat give you, but then you collect info about the plotted (and processed) data - and then save that probably-much-smaller data that for plotting w/ a base ggplot2 spec (i.e. geom_step vs geom_roc)? Mostly, I need to know how layer_data() fits into the cake analogy, and if it should! 🍰 Wondering if layer_data() use, while exported, has a role here.

[clauswilke]

@EvaMaeRey I shouldn't have to create a plot just to calculate AUC. That's what feels so wrong to me.

In general, I feel layer_data() is for testing or debugging purposes. It makes me very uncomfortable when packages rely on it to implement features. It's internal data and a geom could change what it stores or how it stores it from one release to the next without thinking of it as a breaking change.

[EvaMaeRey]

calc_auc() definitely feels a little out of the blue. For developers that want to engage in within-plot computation, it does feel like the compute defined for plotting should/could at least do double duty, but as you say, maybe not via the layer_data().