Cache the query result. #5112
Cache the query result. #5112
Conversation
In a test on rust-lang#4810 (comment) Before we got to 1700000 ticks in ~97 sec After we got to 1700000 ticks in ~92 sec And query disappears from the flame graph
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
Thanks! Upon seeing this though I wonder if we could perhaps do something like: struct CachingRegistry<'a> {
inner: &'a mut Registry + 'a,
cache: HashMap<...>,
}
impl<'a> CachingRegistry<'a> {
fn query(&mut self, ...) -> ... {
// ...
}
}and then pass that around instead of |
|
That would be cleaner. But would Mabe all the We will need a cleaner strategy, looks like multiple test are run on the same thread. |
|
Oh for sure yeah it can't implement |
|
Ok I will play with that tomorrow. :-) |
|
Dose that look better? |
|
Nice! As one final thing, is the |
|
I had gotten the impression that impl hash was not possible for dep. Now I don't know why. It is fixed. |
|
@bors: r+ |
|
📌 Commit cb0df8e has been approved by |
Cache the query result. Small performance gain. In a test on #4810 (comment) Before we got to 1700000 ticks in ~97 sec After we got to 1700000 ticks in ~92 sec. I just reran and got ~82, so it seems to be unstable. And query disappears from the flame graph
|
☀️ Test successful - status-appveyor, status-travis |
Caching the dependencies There are 2 sources of facts for the resolver: 1. The `Registry` tells us for a Dependency what versions are available to fulfil it. 2. The `Summary` tells us for a version (and features) what dependencies need to be fulfilled for it to be activated. The `Registry` was cached with a `RegistryQueryer` back in #5112. This adds a `DepsCache` to cache the calculation of which dependencies are activated by features. In the happy path `flag_activated` means that we don't get to reuse `build_deps`, but the more we backtrack the more time we save. In pathological cases like #6258 (comment), I have measured this as a 10% improvement with release. This also means that `build_deps` can be run in a context free way, which may be useful in a follow up PR to solve #6258 (comment).
Small performance gain.
In a test on #4810 (comment)
Before we got to 1700000 ticks in ~97 sec
After we got to 1700000 ticks in ~92 sec. I just reran and got ~82, so it seems to be unstable.
And query disappears from the flame graph