Move iter_results to dyn FnMut rather than a generic #84719
Conversation
This means that we're no longer generating the iteration/locking code for each invocation site of iter_results, rather just once per query. This is a 15% win in instruction counts when compiling the rustc_query_impl crate.
|
r? @davidtwco (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors try @rust-timer queue to validate my local perf results, and confirm this isn't a runtime regression |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit a1d7367 with merge 002ba80ff7533e2b30773f2e042f18ab661cef2f... |
|
☀️ Try build successful - checks-actions |
|
Queued 002ba80ff7533e2b30773f2e042f18ab661cef2f with parent 18587b1, future comparison URL. |
|
Finished benchmarking try commit (002ba80ff7533e2b30773f2e042f18ab661cef2f): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
rustbot
removed
the
S-waiting-on-perf
|
Looks like an excellent result. Much less expected in practice on parallel (rather than -j1) execution, but should still help with end-to-end times by freeing up some cores sooner.
|
|
There do seem to be runtime regressions for some of the benchmarks in the perf run though? |
|
I'm not sure specifically what you refer to, but I'm not seeing anything that would indicate a large win like this being not warranted. There are some tiny instruction count regressions on very small benchmarks and some larger (but still in absolute terms small) regressions in wall time on one or two benchmarks; I think the win to rustc bootstrap more than exceeds those minor losses myself. |
|
@bors r=davidtwco |
|
📌 Commit a1d7367 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
| let mut res = Ok(()); | ||
| cache.iter_results(&mut |key, value, dep_node| { | ||
| if res.is_err() { | ||
| return; | ||
| } | ||
| if Q::cache_on_disk(tcx, &key, Some(value)) { | ||
| let dep_node = SerializedDepNodeIndex::new(dep_node.index()); | ||
|
|
||
| // Record position of the cache entry. | ||
| query_result_index.push((dep_node, AbsoluteBytePos::new(encoder.encoder.position()))); | ||
|
|
||
| // Encode the type check tables with the `SerializedDepNodeIndex` | ||
| // as tag. | ||
| match encoder.encode_tagged(dep_node, value) { | ||
| Ok(()) => {} | ||
| Err(e) => { | ||
| res = Err(e); | ||
| } | ||
| } | ||
| } | ||
| Ok(()) | ||
| }) | ||
| }); | ||
|
|
||
| res |
There was a problem hiding this comment.
Why not use a short circuit version for this?
There was a problem hiding this comment.
I don't know what exactly you mean, but we don't really care about performance on the error path - the goal here is to minimize monomoprhizations and logic in general.
This means that we're no longer generating the iteration/locking code for each invocation site of iter_results, rather just once per query (roughly), which seems much better: this is a 15% win in instruction counts when compiling the rustc_query_impl crate. The code where this is used also is pretty cold, I suspect; the old solution didn't fully monomorphize either.