Reducing Cargo target directory size with -Zno-embed-metadata

Summary

Disk usage of the target directory is a commonly cited annoyance with Rust (and Cargo) – in the last year’s Annual Survey, it was the third most pressing issue of Rust users, right after slow compilation and subpar debugging experience. Given the “build everything from source” compilation model of Rust, and both debuginfo and incremental compilation being enabled by default in the dev Cargo profile, it is unlikely that the target directory will ever become lean and small. However, there are still ways of how we could reduce the target directory size by a non-trivial amount. I will describe a brand-new method of achieving that in this blog post. Note that there are also initiatives to reduce the size of the target directory along the temporal axis, i.e. prevent it from ballooning over time (see Cargo Garbage Collection). This post is more about how to reduce the size of the target directory overall. What takes up the space, anyway? It is not the focus of this post to dive deep into exploring what exactly takes space in the target directory, but I still think that it is useful to provide at least some background on this. I took my favourite work project, hyperqueue, and compiled it in several modes to compare the resulting target directory sizes, using rustc 1.89.0-nightly (2eef47813 2025-05-22): Optimizations Incremental Debuginfo target size [MiB] No (dev) No No 462 No (dev) Yes No 677 No (dev) No Yes 870 No (dev) Yes Yes 1316 Yes (release) No No 396 From the results, it’s clear that both debuginfo and incremental compilation caches take a lot of space on disk. It might be that we could do something to reduce either of these, but there is one additional thing that (kind of unnecessarily) causes target directory bloat, which is not easily observable in this table, and that is the metadata of the compiled Rust crates. First, we need to briefly talk about how Rust compilation works (in very, very simplified terms). When a Rust library crate (rlib) is compiled in a “sta...