Add project-based index caching to speed up initial load of index

[xhocquet]

This feature is VS Code specific

• VS Code specific

Use case

My workflow involves switching between projects when I want to work in another repo/folder, as opposed to keeping them all open in separate VSCode windows. I find this consumes less resources and helps me maintain focus. Adding some initial caching to the ruby-lsp indices could help me start navigating 5+ seconds quicker when I switch projects.

Description

I would imagine that upon finishing indexing the project, you could, based on configuration, store the index in some file representation in the project folder (or elswhere).

When opening the project from then on, the latest index could be immediately supplied to ruby-lsp to offer finding definitions and other features as soon as the project loads. In the meantime, the index could be rebuilt and refreshed in the background, and set as the active index once ready.

Implementation

Suggested above, but I suppose the main limitation is if you can persist and feed indices to ruby-lsp easily.

[vinistock]

Hello. Thank you for the feature suggestion! This issue is not VS Code specific, since indexing happens on the server. I'm transferring it to the ruby-lsp repo.

This is basically the same as #1009, but for project files.

The main thing to note here is that the implementation for restoring the cache has to be very efficient or else there's actually not a major difference in indexing time due to all of the prefix tree inserts and hash merging.

Also, keeping the cache for project files is slightly more complex. Gems can be cached by version number, since we know their contents won't change if the version is still the same. For project files, we're probably going to need some sort of identifier using the hashed contents of the file to know if the file changed and we need to reindex.