You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Auto merge of #14692 - x-hgg-x:resolver-perf-5, r=Eh2406
fix(resolver): share conflict cache between activation retries
### What does this PR try to resolve?
Found in Eh2406/pubgrub-crates-benchmark#6.
Currently the resolve is done in a loop, restarting if there are pending dependencies which are not yet fetched, and recreating the conflict cache at each iteration.
This means we do a lot of duplicate work, especially if the newly fetched dependencies has zero or few dependencies which doesn't conflict.
This also means that the maximum depth of the dependency graph has a big impact on the total resolving time, since adding a dependency not yet seen means we will restart the resolve at the next iteration.
Here is the output of the resolve for the master branch using `solana-core = "=1.2.18"` in `Cargo.toml`, printing the duration from the start after each iteration:
```
Updating crates.io index
103.142341ms [=====> ] 1 complete; 0 pending
118.486144ms [========> ] 2 complete; 0 pending
785.389055ms [===========> ] 62 complete; 0 pending
4.916033377s [==============> ] 277 complete; 0 pending
9.13101404s [=================> ] 439 complete; 0 pending
50.083251549s [====================> ] 520 complete; 0 pending
133.401303265s [=======================> ] 561 complete; 0 pending
214.120483345s [==========================> ] 565 complete; 0 pending
294.180677785s [=============================> ] 566 complete; 0 pending
Locking 536 packages to latest compatible versions
```
To improve the situation, this PR moves the conflict cache outside the activation loop so it can be reused for all iterations.
This is possible since when using an online registry, dependencies which are not yet fetched are not added to the candidate summary:
https://github.com/rust-lang/cargo/blob/82c489f1c612096c2dffc48a4091d21af4b8e046/src/cargo/core/resolver/dep_cache.rs#L248-L266
On the other hand, if a dependency query returns `Poll::Ready`, then all compatible summaries are returned, so we cannot have a partial view where only some compatible summaries would be returned. This means we cannot add a conflict in the cache which would be incompatible with future fetches, and therefore the conflict cache can be shared.
Here is the output of the resolve with this PR:
```
Updating crates.io index
98.239126ms [=====> ] 1 complete; 0 pending
127.528982ms [========> ] 2 complete; 0 pending
821.601257ms [===========> ] 62 complete; 0 pending
4.67917132s [==============> ] 277 complete; 0 pending
5.933230172s [=================> ] 431 complete; 0 pending
14.74321904s [====================> ] 508 complete; 0 pending
24.607428893s [=======================> ] 546 complete; 0 pending
24.700610469s [==========================> ] 550 complete; 0 pending
24.757651875s [=============================> ] 551 complete; 0 pending
Locking 536 packages to latest compatible versions
```
Besides the huge performance savings between iterations, sharing the conflict cache has the side effect of eliminating dead paths earlier in the resolve after a restart. We can see that the duration of all iterations using this PR is less than the duration of the last iteration on master, and that it needs to resolve less dependencies overall.
0 commit comments