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

[partitioning] Don't create CGUs below a certain size #47318

Closed
michaelwoerister opened this issue Jan 10, 2018 · 5 comments
Closed

[partitioning] Don't create CGUs below a certain size #47318

michaelwoerister opened this issue Jan 10, 2018 · 5 comments
Labels
A-incr-comp Area: Incremental compilation C-enhancement Category: An issue proposing an enhancement or a PR with one. C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@michaelwoerister
Copy link
Member

As a followup to #47316: Once we have a more accurate metric for CGU-size, we can also make sure to not sub-divide the program into smaller units than makes sense -- i.e. we don't want to have programs consisting of 16 one-function object files. We'd first have to find out concrete values for what is "too small" though. And I expect this to have little impact in practice. Consider it a mostly aesthetic improvement.

@michaelwoerister michaelwoerister added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jan 10, 2018
@michaelwoerister
Copy link
Member Author

I have no data to back this up but this might allow to reduce our bootstrap time because it would affect most test cases? cc @rust-lang/infra

@aidanhs
Copy link
Member

aidanhs commented Jan 22, 2018

Just to re-state to make sure i understand: the intention would be to speed up bootstrap, while avoiding the test slowdown seen in #44675 (comment) by avoiding splitting to ensure multiple codegen units don't penalise many tiny compiles?

@michaelwoerister
Copy link
Member Author

The hope would be that most test cases, which are usually small, would end up being compiled to just one codegen unit. As a result, compiling each test case would be faster because we are skipping unnecessary overhead that is introduced by splitting things into multiple CGUs.

This could be tested by making compiletest set -Ccodegen-units=1 for run-pass for example. If that makes the test suite execute faster then the optimization proposed here could be tuned to do so too.

@aidanhs
Copy link
Member

aidanhs commented Jan 23, 2018

Sounds like the previous PR might be worth looking at again as low hanging fruit then, with this being a more robust solution.

@pnkfelix pnkfelix added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 20, 2018
@wesleywiser wesleywiser added the A-incr-comp Area: Incremental compilation label Aug 19, 2020
@workingjubilee workingjubilee added the C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such label Oct 8, 2023
@Mark-Simulacrum
Copy link
Member

This seems to have been implemented:

const NON_INCR_MIN_CGU_SIZE: usize = 1800;
in #112448.

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. C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such 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

6 participants