incr.comp.: Use DefPathHash-based DepNodes in the serialized DepGraph and remove obsolete DefIdDirectory #42332
Conversation
… and remove obsolete DefIdDirectory.
|
Some numbers for compiling New implementation
Current implementation
I'd say the timings are pretty much equivalent. The on-disk graph gets bigger though. I'll look into a more efficient on-disk representation (which should be pretty similar to what we soon want to do anyway). |
aidanhs
added
the
S-waiting-on-review
|
One more thing: This change slightly regresses the output of This could be fixed by storing some additional information with the DepGraph in case |
|
OK, I have a proof of concept implementation of a new dep-graph encoding: New DepGraph Encoding
Looks like that slightly improves re-build times and uses less space than before the PR. I'll clean it up and push it. |
|
Ready for review. |
michaelwoerister
force-pushed
the
no-more-retracing
branch
from
fdd6ae8 to
a3417bf
Compare
| @@ -676,6 +680,40 @@ impl<'a, 'gcx, 'tcx> TyCtxt<'a, 'gcx, 'tcx> { | |||
| let max_cnum = s.cstore.crates().iter().map(|c| c.as_usize()).max().unwrap_or(0); | |||
| let mut providers = IndexVec::from_elem_n(extern_providers, max_cnum + 1); | |||
| providers[LOCAL_CRATE] = local_providers; | |||
|
|
|||
| let def_path_hash_to_def_id = if s.opts.build_dep_graph() { | |||
There was a problem hiding this comment.
seems like a good place for a comment kind of explaining roughly what this table is for -- but a question: does this include only foreign crates? I don't see where it adds LOCAL_CRATE to the table...
There was a problem hiding this comment.
The local crate is added below via chain()
|
@bors r+ |
|
📌 Commit a3417bf has been approved by |
…akis incr.comp.: Use DefPathHash-based DepNodes in the serialized DepGraph and remove obsolete DefIdDirectory With this PR we don't store the dep-graph as a set of `DepNode<IndexIntoDefIdDirectory>` anymore but instead as a set of `DepNode<DefPathHash>`. Since a `DefPathHash` is a global identifier that is valid across compilation sessions, we don't need the `DefIdDirectory` anymore. Since a `DepNode<DefPathHash>` is bigger than a `DepNode<IndexIntoDefIdDirectory>` and our on-disk encoding of the dep-graph is inefficient, this PR will probably increase the amount of space the dep-graph takes up on disk. I'm in the process of gathering some performance data. The changes in here are a step towards implementing ICH-based `DepNodes` (#42294). r? @nikomatsakis
|
☀️ Test successful - status-appveyor, status-travis |
With this PR we don't store the dep-graph as a set of
DepNode<IndexIntoDefIdDirectory>anymore but instead as a set ofDepNode<DefPathHash>. Since aDefPathHashis a global identifier that is valid across compilation sessions, we don't need theDefIdDirectoryanymore.Since a
DepNode<DefPathHash>is bigger than aDepNode<IndexIntoDefIdDirectory>and our on-disk encoding of the dep-graph is inefficient, this PR will probably increase the amount of space the dep-graph takes up on disk. I'm in the process of gathering some performance data.The changes in here are a step towards implementing ICH-based
DepNodes(#42294).r? @nikomatsakis