100MB of Rust Intelligence

Rust-analyzer is one of the best LSPs ever written. It's also a memory hog that will happily eat 8GB on a medium workspace and 16GB if you keep two IDE windows open. I know this because I've watched it happen on my own machine, and because matklad — the developer who just shipped Rust Glancer — literally opened a second VS Code window to make the point.

His alternative: a Rust LSP that targets under 100MB of RAM for reasonable projects. And it works. I cloned the repo, read 429,000 lines of Rust, and tried to understand how he pulled it off.

The Architecture Move

Rust-analyzer's memory problem comes from three design choices that made sense at the time:

• Salsa — an incremental query database that keeps everything in memory because it was designed for IDE-speed responsiveness
• Rowan — a tree-based syntax representation that causes heavy memory fragmentation (the RSS you see in htop is higher than what's actually allocated)
• Always-on incrementalism — every keystroke triggers partial reparsing and re-analysis

Rust Glancer rejects all three in one bet: frozen workspace analysis that gets serialized to disk between queries.

graph TD
  subgraph "rust-analyzer"
    A[Edit keystroke] --> B[Partial reparse]
    B --> C[Update Salsa DB in RAM]
    C --> D[Recompute queries]
  end
  subgraph "Rust Glancer"
    E[Edit keystroke] --> F[Shallow analysis of current body]
    F --> G[Reuse saved index from disk]
    G --> H[Full reindex on save only]
  end
  style A fill:#27272a,stroke:#a78bfa
  style B fill:#27272a,stroke:#52525b
  style C fill:#27272a,stroke:#a78bfa
  style D fill:#27272a,stroke:#52525b
  style E fill:#27272a,stroke:#a78bfa
  style F fill:#27272a,stroke:#52525b
  style G fill:#27272a,stroke:#6d5eb0
  style H fill:#141416,stroke:#22c55e

The insight is brutal in its simplicity: you don't need incrementality on every keystroke. When you type, Rust Glancer does a shallow pass over the current function body. Full analysis — type inference, trait resolution, the whole pipeline — only happens on save. New items (imports, structs, traits) won't appear in completions until you save the file. The author says you get used to it in an hour, and I believe him because the tradeoff is 16GB → 100MB.

What's Under the Hood

4 months, 429K lines of Rust, and a crate structure that reads like a compiler textbook:

• crates/engine/ty — full type inference engine with a proper inference table
• crates/engine/body-ir — body lowering with closure support, closures, associated type projection
• crates/vendor/macro-expand — declarative macro expansion (the author now hates declarative macros)
• crates/engine/analysis — completions, hover, inlay hints, goto definition, references
• crates/lib/profile — a profiling stack that measures performance, memory, and cache behavior on every benchmark run

The memory story goes deeper than "offload to disk." The project implements:

• Allocation lifetime alignment — aligning when transient data gets freed to reduce fragmentation
• Engine-as-a-subprocess — a separate process for analysis so that freeing memory actually returns it to the OS
• Sharded cache — per-package cache files that only load what's needed for the current query
• Purge points — explicit lifecycle hooks that call allocator-specific cleanup between indexing phases

The last one is fascinating: ProjectMemoryPurgePoint enum marks exactly when large transient data dies (after syntax eviction, after def-map build, after body-IR build) and lets the allocator reclaim aggressively. Rust-analyzer never does this because its architecture assumes everything should stay warm in memory.

The LLM Elephant

The post is refreshingly honest about LLM use. The author is clear: this was built with heavy LLM assistance, but not vibe coding. Each PR is verified. Git history shows multi-day gaps between 10K-line changes. The feedback loop was:

1. Build something new
2. LLM proposals seem reasonable → go with them
3. Something bugs me → think for a while → see a design flaw
4. Work with LLM to fix it (sometimes for a week if the screw-up was big)

I've written about LLM-assisted development before, and this is the honest version of it. The model accelerates, the human steers. The author's one request — "do not reduce me to a clanker. It is my code, so if you consider it to be slop, call it my slop, not AI." — lands because he earned it.

What's Missing

Rust Glancer is not a rust-analyzer replacement yet. Missing features include:

• Code actions (implement trait, auto-import)
• Build scripts / proc macro support (needs untrusted code execution — a deliberate exclusion)
• Nightly feature support
• The new trait solver

But the stuff that works — goto definition, hover, inlay hints, completions, references — covers 90% of daily LSP usage. For a 4-month project that started as "smart ctags for Rust" and accidentally became a full LSP, that's remarkable.

Bottom Line

Rust Glancer is the strongest argument I've seen for frozen analysis as a design philosophy in developer tooling. The bet is simple: trade keystroke-level incrementality for an order-of-magnitude memory reduction. For most developers — especially those on 8GB machines, multi-workspace setups, or agent workflows with heavy out-of-editor changes — that trade is worth making.

The 100x RAM claim (16GB → ~100MB) is real for the use case the author optimized for. Your mileage will vary with workspace size. But the architectural lesson applies far beyond Rust: if your tool keeps everything in memory because "speed," you might be paying a tax you don't need to pay.

---