Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Don't enqueue onto a disabled dep_graph. #36973
Conversation
I used to have this setup, but I changed it to the current one specifically so that the shadow graph was active even if incremental is disabled. This is because it detects common errors that are otherwise overlooked (at least until people are using incremental by default). Perhaps we could do this setup, but only if debug-assertions are not enabled? |
|
FYI: As far as I know, debug assertions are always enabled on the build bots. |
|
@michaelwoerister: I think it's the exact opposite (at least on the stable/beta/nightly build bots): |
|
@TimNN I might not be using the right terminology. What I meant was that the tests that gate whether a PR gets merged are run using a compiler where debug assertions are enabled. |
|
Ah well, I suppose those are build bots as well. (Not sure if there is an "official" terminology). (And I just checked, |
|
@TimNN Thanks for making facts out of my speculations |
|
Ok, I will update the code to still push the messages if debug assertions are enabled. |
| @@ -19,15 +19,21 @@ pub struct DepTask<'graph> { | |||
|
|
|||
| impl<'graph> DepTask<'graph> { | |||
| pub fn new(data: &'graph DepGraphThreadData, key: DepNode<DefId>) | |||
| -> DepTask<'graph> { | |||
| data.enqueue(DepMessage::PushTask(key.clone())); | |||
nikomatsakis
Oct 11, 2016
•
Contributor
Have you measured the impact of this on the perf also when construction is enabled? When I first wrote the code, I went to some lengths to make it straightline and cheap when the graph was enabled, and the overhead I measured was quite low. The idea was that copying into the buffer without a branch could actually be cheaper than not copying at all. I did measure and I recall finding this to be the case (I think I tested libsyntax), but a lot has changed since then, and for all I know my measurements at the time were flawed. =) We have a better setup now.
(After all, we do expect "incremental enabled" to be the common case, right? I would think that incr will always be on, unless you are building a final release artifact, in which case you are already asking for a lot of time to be spent on optimization.)
Have you measured the impact of this on the perf also when construction is enabled? When I first wrote the code, I went to some lengths to make it straightline and cheap when the graph was enabled, and the overhead I measured was quite low. The idea was that copying into the buffer without a branch could actually be cheaper than not copying at all. I did measure and I recall finding this to be the case (I think I tested libsyntax), but a lot has changed since then, and for all I know my measurements at the time were flawed. =) We have a better setup now.
(After all, we do expect "incremental enabled" to be the common case, right? I would think that incr will always be on, unless you are building a final release artifact, in which case you are already asking for a lot of time to be spent on optimization.)
|
The only measurement of incremental compilation I did is of |
|
Seems good. @bors r+ |
|
|
Don't enqueue onto a disabled dep_graph. This commit guards all calls to `DepGraphThreadData::enqueue` with a check to make sure it is enabled. This avoids some useless allocation and vector manipulations when it is disabled (i.e. when incremental compilation is off) which improves speed by 1--2% on most of the rustc-benchmarks. This commit has an observable functional change: when the dep_graph is disabled its `shadow_graph` will no longer receive messages. This should be ok because these message are only used when debug assertions are enabled. r? @nikomatsakis
|
@bors: r- Unfortunately I think this caused this failure, specifically: This happened on MSVC for me but not on Linux, and I had to take it out of a rollup as a result. |
This commit guards all calls to `DepGraphThreadData::enqueue` with a check to make sure it is enabled. This requires distinguishing between a "fully enabled" and an "enqueue-enabled" graph. This change avoids some useless allocation and vector manipulations when the graph is disabled (i.e. when incremental compilation is off) which improves speed by ~1% on some of the rustc-benchmarks.
|
I've fixed the problem and pushed an updated commit. The problem was that I mistakenly removed the the enabled check in |
|
@bors r+ |
|
|
|
|
Don't enqueue onto a disabled dep_graph. This commit guards all calls to `DepGraphThreadData::enqueue` with a check to make sure it is enabled. This avoids some useless allocation and vector manipulations when it is disabled (i.e. when incremental compilation is off) which improves speed by 1--2% on most of the rustc-benchmarks. This commit has an observable functional change: when the dep_graph is disabled its `shadow_graph` will no longer receive messages. This should be ok because these message are only used when debug assertions are enabled. r? @nikomatsakis
This commit guards all calls to
DepGraphThreadData::enqueuewith acheck to make sure it is enabled. This avoids some useless allocation
and vector manipulations when it is disabled (i.e. when incremental
compilation is off) which improves speed by 1--2% on most of the
rustc-benchmarks.
This commit has an observable functional change: when the dep_graph is
disabled its
shadow_graphwill no longer receive messages. This shouldbe ok because these message are only used when debug assertions are
enabled.
r? @nikomatsakis