Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce size of target directory #66348

Open
Diggsey opened this issue Nov 12, 2019 · 5 comments
Open

Reduce size of target directory #66348

Diggsey opened this issue Nov 12, 2019 · 5 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-cargo Relevant to the cargo team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Diggsey
Copy link
Contributor

Diggsey commented Nov 12, 2019

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.
@JuanPotato JuanPotato added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) C-enhancement Category: An issue proposing an enhancement or a PR with one. T-cargo Relevant to the cargo team, which will review and decide on the PR/issue. labels Nov 13, 2019
@jonas-schievink jonas-schievink added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Nov 13, 2019
@Diggsey
Copy link
Contributor Author

Diggsey commented Nov 15, 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?

@memoryruins
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

@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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-cargo Relevant to the cargo team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants