# Port rust-analyzer to salsa 3.0

## 2024-12-18

rust-analyzer is on new Salsa on a branch! Tests pass; correctness is good, but performance/memory usage has a concerning regression.

### Performance
* things are working but memory usage / perf is not great
* land 614 helps a lot
* then we can strip out the associated fields on the interned fields

For SyncTable/MemoTable on interned functions, Niko's had an idea:

Somehow, statically declare that an interned struct will *never* have an associated query. Neither `MemoTable` or `SyncTable` are needed unless when it's the argument to a tracked function. Removing it from a few cases could be a substantial, further win.

Takeaways for David:

* Do a memory profile of usage and see and then go from there analyze performance. Not enough data to go on, but the gut feeling is there's some dumb things nobody actually looked at yet.

Niko:
* Will merge various PRs from Lukas

### Debug Information

We'd like to get the debug information for the status command + richer analysis stats.

* Need to resurrect "debug information"
* https://github.com/rust-lang/rust-analyzer/blob/0a706f7d2ac093985eae317781200689cfd48b78/crates/rust-analyzer/src/cli/analysis_stats.rs#L274-L286
* for a given tracked fn, get all the cached results
* https://github.com/rust-lang/rust-analyzer/blob/fa4a40bbe867ed54f5a7c905b591fd7d60ba35eb/crates/ra-salsa/src/debug.rs#L26

The high-level appoach:
* tracked fn has some associated salsa struct type and memo index
* iterate over all pages to find those with the associated type id
* for each slot in the page, find the memo at that index
* if there is one, you can extract the associated value

The downside of this approach is that since page location is stored on the ID (and we do not have the ID when trying to get all data!), we need to scan through a bunch of pages/tables and match on type ID. this is fine, given that we'd basically never *not* want to scan all data when trying to get these stats.

## older stuff

### ids

rust-analyzer packs a bunch of ids into one struct to save memory

hard commitment-- ids are u32

soft commitment -- salsa starts from 0 and moves up, so stealing high bits is "ok" (though you want to do some assertions, we don't guarantee we won't use it)