feat: improve CPU usage #10088
feat: improve CPU usage #10088
Conversation
It doesn't make sense for the prime_caches itself send begin/end events -- the caller knows perfectly fine when they happen!
Let's have only one place where we start delayed ops
There should be only one place where we need to check if we want to start background activities.
|
I think you mentioned the wrong issue in the last commit. |
|
Seems to work! It even has this fun effect that, after typing, the indexing restarts at the crate it was finished at -- that's because the coalescing code just rushes thorough already analyzed crates. I wonder if we can add "is this fresh?" query to salsa, so that we can actually implement this, instead of relying on timing? bors r+ |
|
bors r- |
|
Canceled. |
closes rust-lang#9922 Turned out to be trivial after preliminary refactor. The intended behavior is that we schedule cache priming once ws become quiescent (that is, we fully load cargo project), and we continue to rschedule it until it completes (priming might get cancelled by user typing into a file).
Oups, how could I, that was almost #9292! bors r+ |
|
I've just realized that bors implements exactly the same concurrency control as we do -- pushes to a branch cancel pending runs, and my |
2 participants
No description provided.