incr.comp.: Load cached diagnostics lazily and allow more things in the cache. #46338
Conversation
kennytm
added
the
S-blocked
src/librustc/dep_graph/graph.rs
Outdated
| dep_node: &DepNode) | ||
| -> Option<DepNodeIndex> { | ||
| pub fn try_mark_green<'a, 'tcx>(&self, | ||
| tcx: TyCtxt<'a, 'tcx, 'tcx>, |
There was a problem hiding this comment.
Nit: use '_' instead of 'a here
There was a problem hiding this comment.
That's a thing now?
|
☔ The latest upstream changes (presumably #46299) made this pull request unmergeable. Please resolve the merge conflicts. |
|
r=me |
The previous method ran into problems because ICH would treat Spans as (file,line,col) but the cache contained byte offsets and its possible for the latter to change while the former stayed stable.
…p on-disk-cache persistence code.
michaelwoerister
force-pushed
the
lazy-diagnostics
branch
from
592e969
to
410f850
Compare
michaelwoerister
changed the title
michaelwoerister
removed
the
S-blocked
kennytm
added
the
S-waiting-on-review
|
OK, travis passed. @bors r=nikomatsakis p=1 |
|
📌 Commit 966eead has been approved by |
michaelwoerister
added
S-waiting-on-bors
incr.comp.: Load cached diagnostics lazily and allow more things in the cache. This PR implements makes two changes: 1. Diagnostics are loaded lazily from the incr. comp. cache now. This turned out to be necessary for correctness because diagnostics contain `Span` values and deserializing those requires that the source file they point to is still around in the current compilation session. Obviously this isn't always the case. Loading them lazily allows for never touching diagnostics that are not valid anymore. 2. The compiler can now deal with there being no cache entry for a given query invocation. Before, all query results of a cacheable query were always expected to be present in the cache. Now, the compiler can fall back to re-computing the result if there is no cache entry found. This allows for caching things that we cannot force from dep-node (like the `symbol_name` query). In such a case we'll just have a "best effort" caching strategy. ~~This PR is based on #46301 (=first 2 commits), so please don't merge until that has landed. The rest of the commits are ready for review though.~~ r? @nikomatsakis
|
☀️ Test successful - status-appveyor, status-travis |
|
This appears to have caused a slight regression in performance -- http://perf.rust-lang.org/compare.html?start=e3ed21272d5f50c37c09f2a7f06c40f56b6ac298&end=6805b016efdfcd99e706003fab1336df73f6811b&stat=wall-time -- was that expected? |
|
Bummer, I would have hoped that the slightly more efficient span hashing implementation would make things faster. But it seems that also encoding and decoding expansion contexts adds some noticeable overhead for some crates. Fortunately it doesn't seem too bad -- except for crates.io again. This one seems to be rather sensitive to span related changes. |
incr.comp.: Speed up span hashing by caching expansion context hashes. This PR fixes the performance regressions from #46338. r? @nikomatsakis
This PR implements makes two changes:
Spanvalues and deserializing those requires that the source file they point to is still around in the current compilation session. Obviously this isn't always the case. Loading them lazily allows for never touching diagnostics that are not valid anymore.symbol_namequery). In such a case we'll just have a "best effort" caching strategy.This PR is based on #46301 (=first 2 commits), so please don't merge until that has landed. The rest of the commits are ready for review though.r? @nikomatsakis