Persistent index storing resolved name and type information (beyond file paths) for faster Find References?

[teraoka-k]

Does it make sense to store precise name resolution and type information in an on-disk database (e.g., SQLite).

By incrementally updating this index for edited or new files, we could speed up queries significantly, while reducing memory usage.

Has such an approach been considered? What are the technical challenges invoved?

I appreciate any insights or references to existing discussions.

Thank you.

[teraoka-k]

There is a related issue (#19951) discussing how simply indexing symbol-to-file-path mappings without precise name resolution does not significantly improve performance.

[ChayimFriedman2]

Serialization is planned, but mostly to improve startup performance, and not everything will be serialized, as this will have a very high disk usage.

[teraoka-k]

I see, thanks! Still, for full-time developers who typically work on one project at a time, even tens of GBs of storage might be an acceptable tradeoff — especially with 1–2TB SSDs being common today.

[flodiebold]

We do cache most name resolutions and type inference results in memory, so if you e.g. do the exact same "Find references" request a second time immediately after the first, it should be pretty fast. But 1. we do not eagerly do type inference on all functions in the project, and 2. type inference results can easily be invalidated by changes to the code. (You can't partition this to "files", changes in any file can have an effect on name resolution in any other file in the crate and any dependent crates.) For point 1, I don't think doing type inference eagerly would be helpful -- you'd at best just be waiting the same time, only earlier, and probably we'd do a lot of work that is never needed. For point 2, reducing unnecessary invalidations of type inference is actually being worked on, as I understand.

[teraoka-k]

Regarding point 1, the idea that "eager type inference isn't useful" assumes a synchronous, blocking model. But in practice, type inference can be done non-blockingly in a background thread, allowing precomputation without interrupting the user.

Also, as projects grow with more dependencies and code, relying only on in-memory caching becomes limiting. If name resolution and type inference results are persisted to storage, they can be reused even after restarts, making it possible to perform only incremental updates. This would avoid repeated long wait times and improve scalability and performance in the long run.

As for point 2, I think that direction is excellent.

[flodiebold]

the idea that "eager type inference isn't useful" assumes a synchronous, blocking model. But in practice, type inference can be done non-blockingly in a background thread, allowing precomputation without interrupting the user.

Yes, we could preemptively do type inference etc. in the background, and we might actually want to do that to show diagnostics in unopened files as well. But it's a complicated question where/when to do this, and we'd still be doing a lot of work that just gets invalidated again when the user types more. Note that we usually need to do type inference for a small percentage of functions when searching for references (only those that contain a candidate).

Also, as projects grow with more dependencies and code, relying only on in-memory caching becomes limiting. If name resolution and type inference results are persisted to storage, they can be reused even after restarts, making it possible to perform only incremental updates. This would avoid repeated long wait times and improve scalability and performance in the long run.

As Chayim mentioned, disk persistence is something that we want to do in principle. It was blocked on the Salsa migration, but that is now done so in principle this could be looked at again AFAIU.

Anyway, I suspect the biggest improvements to reference search performance will come from the trait solver switch and the ensuing performance improvements to inference. Inferring all functions that have a candidate should usually not take too much time, but our trait solving is often quite slow at the moment.

[teraoka-k]

I see now. The overall approach is already considering persistent storage for caching.

I agree that if type inference can be significantly accelerated, the need for caching would disappear, which would be ideal.

As for caching, I understand that the immediate practical challenge is whether we can use Salsa’s persistent cache.

Thanks for the clarification!

[teraoka-k]

As for caching, I understand that the immediate practical challenge is whether we can use Salsa’s persistent cache.