--- title: Rust Glancer | daily.dev description: An informal, exploratory commentary on Rust Glancer, a memory-efficient functional LSP server for Rust that uses two orders of magnitude less RAM than... canonical: https://daily.dev/posts/rust-glancer-luznk4gex twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Rust Glancer | daily.dev og:description: An informal, exploratory commentary on Rust Glancer, a memory-efficient functional LSP server for Rust that uses two orders of magnitude less RAM than... og:url: https://daily.dev/posts/rust-glancer-luznk4gex og:image: https://api.daily.dev/og/posts/luZnK4gex.png og:image:alt: Rust Glancer og:image:width: 1200 og:image:height: 630 og:locale: en --- [matklad](https://daily.dev/sources/matklad) [Read post](https://api.daily.dev/r/luZnK4gex) # [Rust Glancer](https://api.daily.dev/r/luZnK4gex "Go to post") An informal, exploratory commentary on Rust Glancer, a memory-efficient functional LSP server for Rust that uses two orders of magnitude less RAM than rust-analyzer. The author (a rust-analyzer maintainer) riffs on architecture tradeoffs: incremental parsing vs. shallow analysis of dependencies, laziness for function bodies, proc macro expansion overhead, file watching bugs in rust-analyzer, and how IntelliJ's PSI model with multiple backends (syntax tree, stub tree, decompiled bytecode) offers a better architectural pattern than rust-analyzer's uniform salsa-based approach. Suggests rust-analyzer should use rustc's .rmeta files for unmodified dependencies instead of running everything through salsa. [#rust](/tags/rust "Check all #rust posts") Aug 21•4m read time•From [matklad.github.io](https://api.daily.dev/r/luZnK4gex "matklad.github.io") [](https://api.daily.dev/r/luZnK4gex "Go to post") Questions this post answers Why does rust-analyzer use so much more memory than a lightweight alternative like Rust Glancer? Rust-analyzer applies its incremental salsa-based data model uniformly to all code, including the thousands of dependencies a project pulls in that are never modified, rather than treating them as read-only. Proc macro expansion adds further bulk since real code must run to expand macros, and at one point roughly 30% of rust-analyzer's binary size was attributed to JSON parsing code pulled in through macro expansion. daily.dev surfaces rust tooling deep-dives for engineers weighing IDE memory tradeoffs. How does IntelliJ's PSI model handle memory efficiently for large projects with many dependencies? IntelliJ's PSI (an AST with resolved types) is backed by three different representations depending on context: concrete syntax trees for files actively open and edited, a compact on-disk Stub Tree storing only externally visible signatures for other project files, and decompiled .class files for external dependencies. The PSI transparently switches between these backends as needed, avoiding full analysis of code the user never touches. developers comparing IDE architectures can track these design patterns on daily.dev. 26.9K Impressions21 Upvotes Comment Bookmark Copy Share your thoughtsPost [](https://daily.dev/sources/matklad) [matklad](https://daily.dev/sources/matklad "https://daily.dev/sources/matklad") Matthias Noback's expertise in PHP and domain-driven design (DDD) offers readers insights into buil... Read more 33 Followers • 474 Upvotes #### Would you recommend this post? Copy link WhatsApp Facebook X New Squad Copy linkShare with your friends 21 ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Rust Glancer","url":"https://daily.dev/posts/rust-glancer-luznk4gex","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/rust-glancer-luznk4gex"},"datePublished":"2026-08-21T19:10:38.520Z","dateModified":"2026-08-21T19:10:58.886Z","description":"An informal, exploratory commentary on Rust Glancer, a memory-efficient functional LSP server for Rust that uses two orders of magnitude less RAM than...","image":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","thumbnailUrl":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","isAccessibleForFree":true,"articleSection":"matklad","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"matklad","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/c34dbbf360354a179786e8a127718b12","url":"https://daily.dev/sources/matklad"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/rust-glancer-luznk4gex","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":21},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"rust","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"matklad","item":"https://daily.dev/sources/matklad"},{"@type":"ListItem","position":3,"name":"Rust Glancer"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/rust-glancer-luznk4gex#faq","mainEntity":[{"@type":"Question","name":"Why does rust-analyzer use so much more memory than a lightweight alternative like Rust Glancer?","acceptedAnswer":{"@type":"Answer","text":"Rust-analyzer applies its incremental salsa-based data model uniformly to all code, including the thousands of dependencies a project pulls in that are never modified, rather than treating them as read-only. Proc macro expansion adds further bulk since real code must run to expand macros, and at one point roughly 30% of rust-analyzer's binary size was attributed to JSON parsing code pulled in through macro expansion. daily.dev surfaces rust tooling deep-dives for engineers weighing IDE memory tradeoffs."}},{"@type":"Question","name":"How does IntelliJ's PSI model handle memory efficiently for large projects with many dependencies?","acceptedAnswer":{"@type":"Answer","text":"IntelliJ's PSI (an AST with resolved types) is backed by three different representations depending on context: concrete syntax trees for files actively open and edited, a compact on-disk Stub Tree storing only externally visible signatures for other project files, and decompiled .class files for external dependencies. The PSI transparently switches between these backends as needed, avoiding full analysis of code the user never touches. developers comparing IDE architectures can track these design patterns on daily.dev."}}]} ```