Reduce size of `target` directory

[Diggsey]

The size of the target directory is becoming a severe problem for me. I use rust at work, and we have many services written in rust. The target directory 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 target directories.

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:

1. I don't think that will actually help much here - the versions of dependencies often differ slightly between services and even a single service can reach the 10 GB limit on its own if left unchecked.
2. Due to the lack of GC, it will become impossible to nuke the target directory for a single service, so the only option will be to nuke everything and then rebuild it all from scratch.

[Diggsey]

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?

[memoryruins]

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.

[bugproof]

This 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...?

[memoryruins]

@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.

[memoryruins]

#87405 is tracking plans to add artifact size profiling, which I suspect will help keep an eye on some contributing factors of this issue.

[jabberwock]

How is this still open?

[Chris00]

See also rust-lang/cargo#7150

[chances]

This issue is a major problem for us resource-constrained developers! Not everyone has "infinite" disk space.

[Diggsey]

[Kobzol]

rust-lang/cargo#17267 might help a bit with the target directory size.