Rust Glancer: A Rust LSP with $\approx 100\times$ Less RAM

Date: 2026-08-19 I want to introduce a project I've spent the last 4 months developing: an alternative implementation of the Rust LSP specifically engineered for minimal memory consumption.

🚀 Core Value Propositions

The project focuses on two primary goals:

• Ultra-low memory footprint: Targeting $\le 100\text{MB}$ for projects of reasonable size.
• Instant post-restart indexing: By persisting the index, restarting your editor doesn't trigger a full re-index.

Note: During the demonstration video, RAM usage consistently stayed below 100MB. These optimizations make Rust Glancer an ideal choice for legacy hardware; for instance, it performs quite well on an 8GB RAM MacBook Pro M1 (2020).

Performance Benchmarks

---

🛠️ Current State of Development

Building a Rust LSP is a massive undertaking, and 4 months is a short window. Consequently, Rust Glancer is a finished product not yet a complete LSP. It contains known bugs and several areas requiring improvement.

However, it is already surprisingly capable:

• Indexing Pipeline: Includes full type inference and a trait solver (via chalk).
• Syntax Support: Most standard Rust syntax is handled.
• LSP Functionality: Core actions are operational, including:
  • goto definition
  • hover
  • inlay hints
  • completions

Get Started:

1. Install the VS Code extension directly.
2. Alternatively, build the .vsix from the GitHub repository.

(For those seeking technical specifics, refer to the project documentation. The following sections detail the project's history, LLM integration, and roadmap.)

---

🔍 Rust Glancer vs. rust-analyzer

To understand why Rust Glancer exists, we must look at why rust-analyzer (RA) is memory-intensive.

The rust-analyzer Challenge

1. Data Volume: Rust workspaces are dense. Indexing thousands of traits, structs, and function bodies is non-negotiable for features like "find all references."
2. Architecture: RA uses an incremental, query-based database. While this allows for lazy computation and partial invalidation (only re-parsing changed bits), it is disk-friendly inherently tied to RAM.
3. Fragmentation: The internal tree-like data structures often lead to heavy memory fragmentation, where the OS allocates more RAM than is actually being utilized.

The Rust Glancer Philosophy

Instead of an incremental approach, I asked: What if we use a frozen analysis result that invalidates only upon saving?

The Trade-offs:

• The Downside: It is slower than RA because loading/deserializing from the filesystem is slower than reading from RAM.
• The Mitigation: To keep the UI snappy, Rust Glancer performs a shallow analysis of the current block during typing while relying on the previous full index.
• The Result: New items (like new imports or traits) aren't fully indexed until you save the document. While this is a shift in workflow, it becomes intuitive very quickly.

---

🤖 Agentic Workflows & Stability

For developers using AI agents that modify code externally, Rust Glancer includes specific optimizations:

• Custom File Watcher: I noticed that in rust-analyzer, agent-driven edits often caused inlay hints to drift or misalign. I resolved this in Glancer by implementing and tuning a custom watcher.
• Priority Management: The server assigns lower priority to out-of-editor changes, ensuring that massive agentic rewrites don't trigger a CPU-melting re-indexing loop.

🏁 Final Outlook

Rust Glancer is not intended to be a "better" rust-analyzer in every metric.

I expect rust-analyzer to remain the gold standard for those who need absolute keystroke precision. Rust Glancer is for those willing to make small trade-offs to reclaim their system memory.

About the Author: I have been a professional Rust developer for $\approx 7$ years. I've closely followed the evolution of the compiler and tooling, contributing to rustc, clippy, and rust-analyzer, and I'