ハクソク

世界を動かす技術を、日本語で。

Rust Glancer: 100倍少ないRAMを使用するRust LSP

2026年8月22日原文(rust-glancer.github.io)

概要

  • 4ヶ月間開発した Rust Glancer は、低メモリ消費を重視した Rust LSP の新実装
  • 100MB未満のメモリ使用 と 即時インデックス復元 が主な特徴
  • 古いPCやメモリ制限のある環境向けに設計
  • rust-analyzerとの違いや設計思想、実装の工夫を詳述
  • 現状の課題や今後のロードマップも公開

Rust Glancer: 低メモリ志向Rust LSPの紹介

  • 4ヶ月間で開発した Rust Glancer、低メモリ消費を最優先に設計
  • 100MB未満 のRAMで動作可能な設計、実際の計測値も公開
  • エディタ再起動後も再インデックス不要、作業効率向上
  • 古いMacBook Pro M1 (8GB RAM) でも快適に動作確認済み
  • VS Code拡張機能 としてすぐに導入・試用可能

主な機能

  • フルインデックスパイプライン、型推論・trait解決（Chalk）対応
  • 一般的なRust構文とLSPアクション（定義ジャンプ、ホバー、インレイヒント、補完など）をサポート
  • インデックス結果をファイルシステムに保存、必要時のみ読み込み
  • シャロー解析 による高速補完、保存時のみフルインデックス更新
  • エージェントによるコード変更 にも最適化、カスタムファイルウォッチャー実装

ベンチマーク結果

  • MacBook Pro M4 Max（36GB）
    • Rust Glancer: インデックス5秒/フル8秒
    • rust-analyzer: インデックス6秒/フル13秒
  • MacBook Pro M1（8GB）
    • Rust Glancer: インデックス6秒/フル9秒
    • rust-analyzer: インデックス7秒/フル14秒

Rust Glancerとrust-analyzerの違い

  • rust-analyzer は salsa （インクリメンタルDB）と rowan （構文木）を採用
    • 高速だが、メモリ消費と断片化が大きい
  • Rust Glancer は インクリメンタル性を捨てて分析結果をファイル保存
    • メモリ消費を抑え、再利用性を重視
    • 保存時のみフル解析、入力中は部分的な解析で応答
  • デメリット ：新しい構造体やimportは保存まで補完候補に反映されない
  • メリット ：低スペックPCや大量プロジェクト同時編集に最適

開発の動機と経緯

  • 7年以上のRust経験、rust-analyzerやrustcなどにも貢献経験あり
  • rust-analyzerのメモリ消費と初期インデックス速度 に課題を感じていた
  • 自身のワークフロー（複数IDE同時起動）で 16GB以上消費 する問題
  • 「 スマートctags for Rust」から始まり、徐々に本格的なLSPへ進化
  • 型推論・trait解決・マクロ展開 などの実装過程で多くの学びと発見
  • Chalk統合 によるtrait解決の効率化
  • プロファイリング基盤 を自作し、性能・メモリ計測とベンチマークを自動化

LLM（大規模言語モデル）の活用

  • 開発初期からLLMを積極活用、設計や実装の参考に
  • PR単位でコード品質を確認しつつ進行
  • コードベースに 詳細なコメント を付与し、可読性・保守性を重視
  • LLMの提案を受けつつも、最終的な設計判断は自分で行うスタイル
  • 学習・成長の過程 としてLLMを活用

今後の課題・ロードマップ

  • 未実装機能や既知バグ が多数存在
  • 補完精度・LSPアクションの充実 が今後の課題
  • ドキュメント充実 や、より詳細なプロファイリング情報の公開を予定
  • rust-analyzerの完全な置き換えは目指さず、用途特化型LSPとして進化予定

導入方法・試用案内

  • VS Code拡張機能 をインストール、またはリポジトリからvsixビルド
  • 詳細は プロジェクトドキュメント 参照

Rust Glancerは、「 低メモリ消費で十分なRust LSP体験」を求めるユーザーに最適な選択肢。 高機能・高精度を求める場合はrust-analyzer、 メモリ効率や軽快さを求める場合はRust Glancerという棲み分けを想定。

Hackerたちの意見

明確に言うと、著者は https://github.com/popzxc で、私じゃないよ！私の考えはここにあるよ: https://matklad.github.io/2026/08/21/rust-glancer.html

└

君の考えはすごく面白い！でも、プロジェクト自体をフィーチャーする方がフロントページのスレッドには合うと思ったから、コメントを統合することにするよ（どんな感じかは別として）https://news.ycombinator.com/item?id=49392654 からのコメントをね。そして君のリンクを上のテキストに追加するよ。これを取り上げてくれてありがとう！

└

カバレッジと優しい言葉、ありがとう！投稿のタイトルは自分が保証できる以上に野心的だけど、頑張ってそれに応えられるようにするよ^_^" 投稿に対するコメントの中で、>「その部分はおそらく遅延処理できるかも（でもインクリメンタルではない！）？」って言ってたけど、まだ遅延処理をどうするか考えてる。非インクリメンタルのアプローチだと、快適に感じる以上の遅延が出ることがあるからね。今はオープンバッファを優先して、ユーザーが必要とするものを早く処理するようにしてる。その他はバックグラウンドでインデックス化してる。遅延アプローチについては考えがあるけど、試す前にまず分析の質を向上させたい。>「Rust Roverとのメモリ使用量を比較するのは面白そうだね。」IDEのGUIを除けば、RRの方がコンパクトだと思う。RRについていくつかコメントもらったけど、正直言って試したことはない（JetBrainsのIDEとは相性が悪くて） -- でも調べてみるよ。>「ここでの一つのアプローチは、Sorbetのトリックを使うことだね。メタプログラミングを全く実行せず、代わりにその効果を“説明”するプラグインインターフェースを持つ。」面白いことに、これがまさに自分が考えてるアイデアで、試してみたいと思ってる。Rust Glancer 0.3.0に仮で計画中（0.2.0は主により完全なインデックス化や機能、エディタのサポートについて）。要するに、LSP自体でランダムなコード実行はしたくない（診断もデフォルトで無効だし）、でもprocマクロにはそれが必要ないかもしれない。>「このオプションを変更してみて、効果があるか試してみて？」エディタとサーバーウォッチャーのオプション両方試したけど、あんまり違いを感じなかったな。ただ、高品質な調査をしたとは言えないけど。VS Codeが外部の変更を正しく報告するのがあまり得意じゃないのは確か（結構見逃すことが多いし）、サーバーウォッチャーを正しく設定するのも難しかった（プラットフォーム特有の quirks が結構あって、Windows用のサーバーを提供するのが不安な理由の一つだね -- テストするマシンがないから）。>「ここはまだ一番簡単に手に入るスイカのように思えるな。世界をアーキポイントのインクリメンタルな氷山の先端と、主に読み取り専用の、ディスク上のコンパクトで暗くて湿った供給チェーン攻撃の温床に分ける。」これ、すごくいいと思う！Rust Glancerが不要になる変化を見られたら本当に嬉しい。実験する能力もクールだけど、最終的には統一されたツールが言語にとっては良いと思う。

なんでみんな略語を説明しないの？Rust LSPって何？

└

Language Server Protocolのことだよ。IDE（VSCodeとか）でリントや構文チェック、「参照に移動」みたいなことをするのに使うんだ。

└

人は期待する聴衆に応じてコミュニケーションをとるんだよ。だから、Rust（システムプログラミング言語）やLSP（VS Codeが作った言語サーバープロトコル）が記事で説明されてないんだ。使った言葉を定義しなくて済むといいんだけど、もし疑問があったらGoogleかChatGPTを使ってみてね。

└

最近のプログラマーの間ではLSPはよく知られた用語だよ。

└

Rustの https://en.wikipedia.org/wiki/Language_Server_Protocol

大きなワークスペースのためにRAがメモリ内データ構造を構築するのを待つのは本当に辛いね。正直、これが唯一の方法だと思ってたから、Rust Roverが違うって気づかなかった。使ったことある人いる？何かトレードオフはあるのかな？

ディスクキャッシュ付きのRAって？

└

一応そうだね。違うアーキテクチャを使ってるから、正確には「何かを伴うRA」ってわけじゃないけど、基本的なアイデアは似てるよ：すべてがディスクにあって、必要なときだけロードされる感じ。

こんにちは！著者です。質問があれば喜んでお答えします。

Hacker Newsで議論の続きを見る