Add API to dump memory usage

[ibraheemdev]

This PR adds the methods <dyn Database>::{structs_info, queries_info}, which allow accessing memory usage information about salsa structs and memos. In ty, this lets us generate a report that looks like this:

=======SALSA DUMP=======
`Definition`                                       metadata=7.21MB   fields=14.41MB  count=180134
`Expression`                                       metadata=4.42MB   fields=4.42MB   count=92086
`member_lookup_with_policy_::interned_arguments`   metadata=1.94MB   fields=2.21MB   count=34566
`class_member_with_policy_::interned_arguments`    metadata=1.56MB   fields=1.78MB   count=27820
`IntersectionType`                                 metadata=0.75MB   fields=1.50MB   count=13350
`OverloadLiteral`                                  metadata=1.19MB   fields=0.85MB   count=21181
...
`Definition -> ty_python_semantic::types::infer::TypeInference`
    metadata=24.41MB  fields=32.41MB  count=144690
`Expression -> ty_python_semantic::types::infer::TypeInference`
    metadata=28.34MB  fields=17.95MB  count=80115
`ScopeId -> ty_python_semantic::types::infer::TypeInference`
    metadata=14.34MB  fields=6.31MB   count=28170
`member_lookup_with_policy_::interned_arguments -> ty_python_semantic::place::PlaceAndQualifiers`
    metadata=4.92MB   fields=1.66MB   count=34566
...

One current limitation is that we cannot provide the name of the query function, only it's input and output types. The other is that this only reports the stack size of any struct fields, which makes this a lot less useful for anything even wrapped trivially in a Box or Arc. Ideally we would have some way of asking a type for it's heap allocation size (maybe using something like the get-size crate), but it would likely have to be opt-in to avoid breakage, and I'm not sure exactly how that would look (maybe a macro attribute, or feature flag?).

I'm not sure how others have been profiling salsa-related memory usage, but the above report has been extremely useful for us. Also unsure if this should be under the salsa_unstable feature.

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	10ce744
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/685594bcba54f3000861b286

[codspeed-hq]

CodSpeed Performance Report

Merging #916 will not alter performance

_{Comparing ibraheemdev:ibraheem/memory-usage-dump (10ce744) with master (87a730f)}

Summary

✅ 12 untouched benchmarks

[MichaReiser]

Sorry, I didn't get to reviewing this today. I plan to review tomorrow. Note, there's a test failure on 1.85

[MichaReiser]

This is great. I think it would be good to gate this behind the unstable feature for now.

It would be nice if we could extract the query name somehow. I left a few ideas but not surehow (and I'm not very familiar with that part of the code). Maybe @Veykril or @davidbarsky have an idea of how we could do that?

[MichaReiser]

I don't have a concrete proposal but I was just wondering if we could somehow use Zalsa::memo_ingredient_indices or maybe the jar_map (by indexing with the erased type id) to get the query ingredient index.

[davidbarsky]

maybe call this ingredients?

[ibraheemdev]

It's not all ingredients, it's only tracked/interned/input structs.

[davidbarsky]

That’s the big three, no? We’d be missing supertypes?

[ibraheemdev]

Queries are also ingredients but they're split out from this method.

Internally there's also a bunch of other things that we call ingredients, but I'm not sure that's relevant for this API (tracked struct fields, etc.).

[davidbarsky]

It would be nice if we could extract the query name somehow. I left a few ideas but not sure
how.

I'm trying to remember, but I also remember struggling with this when I last touched this.

[MichaReiser]

@carljm any chance you know how to get the query name?

[carljm]

@carljm any chance you know how to get the query name?

Not off the top of my head, no, I'd need to spend some time looking at it.

[ibraheemdev]

The problem is that memos are stored on the input ingredients, which are completely disconnected from the query ingredient. I think the only way to do this would be to store the type name on MemoEntryType, which is probably not something we want to do (except maybe under a feature flag?).