Huge memory usage by rust analyzer

[learncodingforweb]

i am developing slint rust app using vscode on ubuntu24.04LTS. But rust-analyzer is taking huge amount of memory usage by multiple tasks of rust-analayzer.

rustc 1.92.0 (ded5c06cf 2025-12-08)
rust-analyzer Version0.3.2719
VSCode Details

Version: 1.107.1
Commit: 994fd12f8d3a5aa16f17d42c041e5809167e845a
Date: 2025-12-17T14:15:14.850Z
Electron: 39.2.3
ElectronBuildId: 12895514
Chromium: 142.0.7444.175
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Linux x64 6.14.0-37-generic

Extensions

rust-analyzer
The Rust Programming Language
rust-lang.org
5,526,603
(238)
Rust language support for Visual Studio Code

Default settings provided by VSCode

[ChayimFriedman2]

Is this a regression? Do you have a reason to believe its exceptional?

Also, I think Slint generates huge amounts of code - this could definitely impact rust-analyzer.

[swordfeng]

Recently I also ran into issues with RA’s memory usage and spent some time investigating it. I enabled the built-in DHAT profiler to better understand where the allocations were coming from. In one case with ~5.6 GB of memory usage, the breakdown looked roughly like this:

• 29% - rowan::green::node::GreenNode
• 19% - span::map::SpanMap<S>
• 24% - tt::TokenTree<S>

Together these accounted for about 72% of the total. My understanding is that these structures mostly represent AST data, and they appear to be retained in memory indefinitely. I might be misunderstanding the design here, so please correct me if that assumption is wrong.

I also looked into the memory layout of these structures to see whether there were opportunities for space savings (assuming 64-bit, 8-byte-aligned machines):

• GreenNode (rowan)
  These are allocated as GreenNodeHead(u16 + u32) plus an array of GreenChild(u32 + ptr). There seems to be a 2-byte gap in the header and a 4-byte gap per child, which works out to roughly ~25% wasted space. In addition, the first u32 (rel_offset) in each child is always 0, so that field could potentially be eliminated entirely.

  I experimented with representing child pointers as 32-bit relative offsets from the first child. Since GreenNodes are immutable, the base address is stable, and with alignment shifts a relative u32 can address roughly ±16 GiB, which seems sufficient for most projects. In practice this yielded about ~37% savings in DHAT runs.

• SpanMap
  SpanMap is currently a Vec of (offset, range_start, range_end, file_id, ast_id, ctx) — six u32s (24 bytes). The first three fields are often small values, which suggests they could potentially be packed into one or two u32s instead. A quick prototype showed modest savings (~25%). I suspect even larger gains might be possible with lightweight compression over the entire vector.

• TokenTree
  TokenTree is an enum-based tree structure, with each node currently 24 bytes. This one is more difficult to optimize because it is used pervasively throughout RA.

With experimental optimizations for the first two structures, I observed around ~16% overall memory reduction. I suspect there is still headroom for further improvement - but I also wonder whether we actually need to keep all of this data in memory all the time, or whether some form of eviction / on-demand loading might be feasible.

Would appreciate any guidance from people more familiar with RA’s design - especially if some of these assumptions are off or if there’s prior work in this direction.