Skip to content

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

New issue

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

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

Already on GitHub? # to your account

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.

# for free to join this conversation on GitHub. Already have an account? # 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