Disabling cache priming by default

[lnicola]

We added cache priming mostly for the convenience of Vim users, but those don't tend to have the best experience without ra-multiplex anyway, and I suspect some Vim users expect their editor to start instantly and without too much fuss.

Without cache priming (and a couple of open files), on self, r-a starts in 8.3 s CPU time and uses 1627 MB RSS. With cache priming, it takes 14.8s and 2225 MB RSS. That's an almost 600 MB difference, on a relatively small repo, but some users will open more of them, and maybe not use them enough to reach a similar memory usage.

In addition, cache priming is:

• annoying on laptops: it's faster these days because of threading, but still makes the fans spin up
• maybe not very clear to users, since we still see complaints about start-up or indexing time

Even if it helps with the total latency overall (especially for Go to Definition etc. without inlay hints) , I still feel that being lighter on start-up is more important.

EDIT: maybe we should ask users to give it a try an chime in?

[ChayimFriedman2]

I disagree. First, cache priming is actually faster than not doing it because of parallelism. Second, the progress bar is important. Third, IMO the solution to startup speed is on-disk cache, not disabling cache priming.

[lnicola]

I know it's faster, but that doesn't translate into a better experience. Without priming, the cost gets amortized over the first seconds/minutes of looking at the code (and inlay hints), scrolling around, switching between files. With it enabled, you're paying a huge initial cost for something you might never use.