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

Wasteful duplication between incremental build dirs and normal artifacts. #70823

Open
eddyb opened this issue Apr 5, 2020 · 0 comments
Open
Labels
A-incr-comp Area: Incremental compilation C-enhancement Category: An issue proposing an enhancement or a PR with one. I-heavy Issue: Problems and improvements with respect to binary size of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@eddyb
Copy link
Member

eddyb commented Apr 5, 2020

Incremental compilation reuses object files by storing a copy of them in the incremental cache directory, which is then copied into the rlib.

This results to build dirs which are twice as big as they need to be (which then gets multiplied by the number of stale artifacts that aren't removed by any tool AFAICT).

There are several ways we could resolve this, but they can be split into two categories:

  • incremental cache holds the object files
    • Cargo could have a mode in which it instructs rustc to emit object files but only in the incremental cache and then downstream rustc to use that incremental cache
      • this would allow non-Cargo tooling to keep working, but we'd have to support rlibs as the same time as the new system and we might unknowingly break them if Cargo doesn't use them
    • the rlib doesn't have to be a real archive, we could have a different format that references the files in the incremental cache, or even make the rlib a directory full of hardlinks, or a hardlink itself etc.
  • rlib artifact holds the object files
    • not clear what's possible at all for other crate types, for now they'd keep the duplication
    • we probably want to hardlink/symlink it from the incremental cache and hash each object file so we can check it's still the same and only reuse it then
      • we might already be doing that hashing anyway, in case the incremental dir is corrupted
    • requires no change in tooling AFAICT, including custom non-Cargo setups

cc @rust-lang/compiler

@eddyb eddyb added A-incr-comp Area: Incremental compilation I-heavy Issue: Problems and improvements with respect to binary size of generated code. labels Apr 5, 2020
@jonas-schievink jonas-schievink added C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-incr-comp Area: Incremental compilation C-enhancement Category: An issue proposing an enhancement or a PR with one. I-heavy Issue: Problems and improvements with respect to binary size of generated code. 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

2 participants