我想展示一个我在过去四个月中一直在工作的项目：一个替代的Rust LSP实现，专注于低内存使用。它有两个主要特点：它可以使用非常少的内存（目标是合理项目的 <100mb）。有一些限制，下面描述了这些限制。它允许在重启后立即索引：如果您的项目已经被索引，重启编辑器将不需要重新索引。您的浏览器不支持嵌入视频。您可以下载录像。注意：在整个视频中，使用的RAM保持在100mb以下。这些功能使得Rust Glancer适合旧电脑：我在我的旧款MacBook Pro M1 2020（8GB RAM）上进行了测试，效果相当不错。机器LSP基础索引（可用引擎）完整索引 MacBook Pro M4 Max，36GB（2025） Rust Glancer 5秒 8秒 MacBook Pro M4 Max，36GB（2025） rust-analyzer 6秒 13秒 MacBook Pro M1，8GB（2020） Rust Glancer 6秒 9秒 MacBook Pro M1，8GB（2020） rust-analyzer 7秒 14秒 可以想象，四个月的时间对于一个如此庞大的Rust LSP项目来说并不算多。Rust Glancer还不是一个完整的LSP，它缺少很多功能，存在一些已知的bug，并且还有很多我想改进的地方。同时，它已经相当强大：它具有完整的索引管道，包含类型推断和trait求解器（chalk），支持大部分“正常”的Rust语法，且大部分“正常”的LSP操作也能正常工作：跳转定义、悬停、内联提示、补全等等。如果您感兴趣，已经可以尝试：只需在这里安装VS Code扩展，或者如果您愿意，可以从仓库中构建并安装vsix。帖子其余部分包含了项目的历史：动机、LLM使用、计划和路线图。如果您不感兴趣，您可以查看项目文档。与rust-analyzer的差异有几个原因使得rust-analyzer消耗大量内存：Rust工作区实际上有很多信息需要被索引：成千上万的函数、结构、trait，它们之间的关系、函数体及其中的语句等。每一个都需要被分析和记住，如果想要实现“找到该结构的所有引用”等功能，您无法通过其它方式解决。rust-analyzer使用salsa作为其数据库。它是一个增量基于查询的数据库，懒惰地计算您需要的所有数据，而无需显式地“记录”所有内容。这是一个非常酷的方式，但它在内存上本质上是绑定的，这使得很难将部分数据从内存中移走。rust-analyzer使用rowan进行语法树表示。这里的一个很酷的属性是，它允许部分失效：如果只有文件的一部分更改，只有相关部分需要重新解析，这使得每次键入时无需重新解析整个文件更快。然而，它的树状表示形式可能会导致严重的内存碎片化（这意味着操作系统分配的RAM数量高于“实际使用”RAM的数量）。这是我们必须忍受的东西（虽然我们可以做一些优化，Rust Glancer已做到这一点），但后两个（即语法树和表示）的后果则是rust-analyzer架构的结果。rust-analyzer选择它们是为了加快LSP速度，而这的确实现了其目的。我在开始这个项目时的想法是：如果我们不尝试制作一个增量LSP，会怎样？如果我们只有一个在保存时失效的静态分析结果呢？显然，它不会像rust-analyzer那么快，但它会给我们我们所寻求的特性：分析结果可以卸载到文件系统中，并仅在实际需要时加载到内存中。保存的分析是可重用的，并且由于它已经卸载到文件系统，可以在编辑器重启后重用。这是Rust Glancer的核心思想。它对工作区进行一次索引并将结果保存在文件系统中，然后每当查询需要某些东西时，它们可以在查询期间加载所需的信息。但这并不是免费的：由于定义上，冻结的工作区分析比懒惰的增量分析更慢，因为从文件系统加载和反序列化数据的速度慢于从内存加载。为了缓解这一点，Rust Glancer必须使用一些技巧：例如，当您输入时，它不会在每次按键时进行全面分析，而是尝试对当前主体进行浅层分析，并重用先前的完整索引。这使补全能够相对快速，但也意味着新项（导入、结构、trait）的“索引”直到您保存文档为止。希望这不成问题：您真的会很快习惯它，至少在我看来，过一段时间后它不会觉得太过奇怪。如果这听起来令人害怕，我建议您尝试一下，真的并不算什么。对于依赖于代理工作流程的人，Rust Glancer也进行了优化。