-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
[experimental] Don't partition generic and non-generic code into different CGUs during incr. comp. #53963
[experimental] Don't partition generic and non-generic code into different CGUs during incr. comp. #53963
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
@bors try |
⌛ Trying commit c481aae427901e3821db90ef91d4f025ac0c497f with merge 01f9f95a596c37b93bbffdc2ef821b761a3e642f... |
cc #53929 |
@rust-timer build 01f9f95a596c37b93bbffdc2ef821b761a3e642f |
Insufficient permissions to issue commands to rust-timer. |
@pnkfelix We should wait for the try build to finish anyway. |
@rust-timer build 01f9f95a596c37b93bbffdc2ef821b761a3e642f |
Success: Queued 01f9f95a596c37b93bbffdc2ef821b761a3e642f with parent b0297f3, comparison URL. |
☀️ Test successful - status-travis |
I think we'll have to redo benchmarking after #53962 has been merged. The effects on |
There are no results yet for |
c481aae
to
4e75f25
Compare
@bors try |
[experimental] Don't partition generic and non-generic code into different CGUs during incr. comp. At the moment we are splitting generic and non-generic code into different CGUs when partitioning the crate during incremental compilation. The reasoning behind this is that generic code might change more often than non-generic code. That reasoning was never properly validated though. Since it's simple to just not split things, let's give it a try and see how it performs.
It seems like what we are seeing in these benchmarks is basically just "bigger CGU means more time to rebuild", I suspect? |
☀️ Test successful - status-travis |
Yes, it's a double-edged sword: If the partition is bigger and it is re-used you'll have saved time when generating it (less redundant work done). But you also increase the amount of work that needs to be re-done if it's not re-used because there are more functions in it that need to be re-compiled although it might just be one or two that actually have changed. |
@rust-timer build 08bf2b2 |
Success: Queued 08bf2b2 with parent 35a5541, comparison URL. |
@michaelwoerister I wonder, could we perhaps ignore |
@alexcrichton I thought that we do that already: rust/src/librustc_mir/monomorphize/item.rs Lines 87 to 90 in b75b047
|
Oh hm perhaps! I guess I was thinking that if you have a crate like: // crate "A"
#[inline]
pub fn foo() {} and then depended on that with: // crate "B"
extern crate a;
pub fn bar() { a::foo(); } we'll codegen (this doesn't apply super well to libstd because it's optimized, so it may not be a good idea in general) |
Yeah, something like that should be doable via the existing |
I opened #54089, so we don't lose track of the idea regarding inline functions. I'm closing this PR since it didn't really work out. |
At the moment we are splitting generic and non-generic code into different CGUs when partitioning the crate during incremental compilation. The reasoning behind this is that generic code might change more often than non-generic code. That reasoning was never properly validated though. Since it's simple to just not split things, let's give it a try and see how it performs.