Open Veykril opened 1 month ago
There's also ArenaMap
that is Vec
, but it is only in bodies source map and those aren't a big part of our memory usage (around 70mb for analysis-stats .
for bodies & source maps).
I'm looking into this but it doesn't look super promising. There are definitely memory savings to be had but they are in the range of single digit megabytes even when looking at big projects (like rust-analyzer
itself). It's still something that should get done eventually but I don't think it's super high priority.
As for why this is the case, you can add an extra column of output to print_memory_usage
that shows the per-entry size (literally total size divided by number of entries) and see that most of these structs are big enough that shaving off 8 bytes is a minuscule improvement. Here's a sample output from analysis-stats -v .
(truncated to the 10 biggest contributors) showing that.
Total: 116.80s, 658ginstr, 1874mb
285mb 27149 10kb MirBodyQuery
236mb 416977 594b TraitSolveQuery
215mb 60670 3722b FileItemTreeWithSourceMapQuery
168mb 30160 5kb InferQuery
149mb 80975 1939b MacroArgQuery
88mb 253301 366b ImplDatumQuery
86mb 32201 2814b BodyQuery
80mb 1583 51kb ExpandProcMacroQuery
46mb 253 187kb CrateDefMapQuery
41mb 186047 233b AttrsQuery
la_arena::Arena
is currently aVec
, that is 3 words in size but usually stored in a frozen location. ForVec
s we usually turn them intoBox<[T]>
when stored as those are only 2 words in size, we can't do that withArena
's though as we have no equivalent. It would be interesting to see if we can save a tiny bit of memory if we could. That means, we should check the places where we store Arena's in hot definitions (frequently used defs stored in queries), and also try to apply the vec -> box pattern in more places (a bunch still use Vecs as using this pattern requires splitting out a builder pattern that transform into the Box'd field form when finished)