Better CPU utilization/battery life

[matklad]

I've noticed (heard the fan) that, if I have a bunch of files open, and type a comment in ide_db/src/defs.rs, CPU usage goes up significantly. This file lives in the core ide crate, so typing it in the worst case can invaidate a bunch of things. Typing a comment shouldn't be that bad.

I think there are several things we might want to do here, long-term:

• make sure that typing comments doesn't invalidate a bunch of salsa queries, and make sure that whatever extra IDE functionality is triggered on top (diagnostics, hightlighting) is fast or cached.
• tweak our cache priming strategy -- it doesn't seem prudent to eagerly re-process everything on every keystroke
• improve latency via parallelism -- we don't need to optimistically per-analyze things if we can just throw all cores at them when the time comes.

At the same time, I don't think we should use the most obvious strategy of just throttling our updates. Batching up keystrokes together helps with power consumption, but it trades latency for throughput. I believe that, by being smart, we can have both low latency and high throughput --- fundamentally, changing a single file a bit most of the time doesn't change the observed state a lot, we just need to figure out how to not do more than we need to.

[matklad]

Seems that our priming caching infra is indeed at least confusing: #9704 (comment)

@jonas-schievink I wonder if you see some quick wins there? One reasonable option might be to only run cache priming on configuration change (that is, when we go non-quiescent -> quiescent). That's a bit tricky to code, because priming might get interrupted by edits, and we should re-run it in that case, but we still want to not re-run it when it completes.

Another option is to make salsa internally-parallel and just get rid of cache priming :o)

[lnicola]

I tried to disable priming and I think it used about 20-25% less CPU usage (200% vs. 250%) when typing, which isn't as good as I expected but still helps if you also consider the client.

[jonas-schievink]

Yeah I don't see anything we can easily do here, but only priming after configuration switching sounds good

[matklad]

Going to close this one -- I think that the new priming strategy fixes the biggest problem here. The second biggest architectural win will come from || salsa.

What's left in terms of actionable things is just looking at the CPU profiles during typing and figuring out how we can do better!