Repository navigation
Reduce size of target directory #66348
Description
Activity
- addedT-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-cargoRelevant to the cargo team, which will review and decide on the PR/issue.Relevant to the cargo team, which will review and decide on the PR/issue.
on Nov 13, 2019 - addedT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.and removedT-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
on Nov 13, 2019 For an example service, the breakdown by file type is:
Extension Size (MB) ---------------------- .rlib 1384 .rmeta 935 .pdb 826 .bin 611 .exe 225 .o 109 .dll 61 .json 28 ...Another thing that stands out to me is that a large proportion of space is taken by the executables and PDB files of build scripts and that these build scripts are all duplicated: once for RLS and once for normal builds. I don't see a reason why RLS couldn't reuse the same build script artefacts as the main build?
For rls, rust-lang/rls#753 (comment) described the issue as
We basically can't share data between RLS and non-RLS because the RLS builds are done with a custom compiler and with different flags.
Reacted by Mateusz Mikuła and Matthew PlanchardThis is a major problem because it eats your disk space quickly even with very small console programs. Couldn't it be stored in some global place so it could be re-used by multiple crates...?
Reacted by ta32, makin, Rohan Bhela, Theo Paris, Shaik Abdul Thouhid, ErrorNoInternet, Alvaro Fernando García, Tim Van Wassenhove, Thomas Barbier, Artrix and 8 more@bugproof cargo has a tracking issue for ways to improve its cache usage rust-lang/cargo#7150 . In the "Reusing shared dependencies" section, it lists a couple options that can be used today.
Reacted by bugproof and Devon Stewart#87405 is tracking plans to add artifact size profiling, which I suspect will help keep an eye on some contributing factors of this issue.
Reacted by Devon StewartHow is this still open?
Reacted by Vinícius Jabes, jabberwock and kittySee also rust-lang/cargo#7150
This issue is a major problem for us resource-constrained developers! Not everyone has "infinite" disk space.
Reacted by jabberwock, Jens Mertelmeyer, kuraga, abbycin, Evgeny and Aworldcrust-lang/cargo#17267 might help a bit with the target directory size.

The size of the
targetdirectory is becoming a severe problem for me. I use rust at work, and we have many services written in rust. Thetargetdirectory for each service is typically 2-3 GB for a fresh build, and increases without bound due to the lack of GC, so that after a short period you're looking at 4 GB per service.For reference, the final size of the musl-based statically compiled binaries we deploy is about 100 MB each, or 40x smaller than the intermediate artefacts, and the majority of that is debug info (once we separate out debug info it's down to maybe 30 MB).
I have a decently sized SSD (500GB), but even so, this very quickly gets out of hand. For various reasons I can only really afford to give 10 GB of space dedicated to the rust services, which means I can only do local development on two at a time (the other services are run by pulling prebuilt docker images with no possibility for local changes) and this is assuming I regularly nuke my
targetdirectories.If I compress a 4 GB target directory with 7-zip, it compresses to about 700 MB, so even if all of the data is required, there's quite a bit of scope for reducing the disk usage. Also, maybe some intermediate artefacts can be deleted entirely and just recreated as needed?
I've seen elsewhere the suggestion to share the target directory between services, but: