63 MB: ブラウザでない Mac のコードエディタが必要とするメモリ

エディタは、けっして終了しないアプリケーションです。ブラウザやメールクライアント、ビデオ会議の後ろで一日中開かれたまま、書きかけの文章を抱えています。それが何を消費するにせよ、消費は一日中続き、しかもあなたが同時にビルドを走らせたいと思っているまさにその機械の上で続きます。

そこで推測はやめて、 MeatPad を実際に測ってみました。ほかのアプリもすべて動いたままの、ごく普通の仕事用 Mac の上でです。

数字

3 つのシナリオ、1 台のマシン、ある午後の記録です。

MeatPad 0.10.2 · macOS 26.5.2 · Apple silicon

ノートウィンドウのみ、19 時間経過        63 MB    ピーク 83 MB
2,721 ファイルのプロジェクト、6 タブ    108 MB    ピーク 131 MB
6.3 MB のテキストファイル 1 つ         1500 MB    後述の正直な節を参照

VS Code 1.130.0、同じフォルダ、同じ 6 ファイル
                                        710 MB    8 プロセス合計

重要なのは真ん中の行です。これが実際の作業状態だからです。本物のリポジトリを開き、ファイルツリー、6 つのタブ、シンタックスハイライト、プロジェクト全体検索、補完がすべて有効な状態。ここで 108 MB に落ち着き、そのまま動きません。131 MB のピークはプロジェクトを最初に走査し、補完用の識別子インデックスを作る処理によるもので、その分はすぐに解放されます。

VS Code の行は対比のためであって、優劣の判定ではありません。ユーザーデータディレクトリを新規に作り、拡張機能は 1 つも入れず、同じフォルダと同じ 6 ファイルを開いて、起動から 1 分後に計測しました。VS Code は MeatPad よりはるかに多くのことができますし、その差の多くは多くの人が当然求めている拡張機能のエコシステムです。ここで比べているのは下限であって、勝ち負けではありません。

自分で確かめる。ただし間違った数字に注意

この点について Mac 上の 2 つのツールは食い違います。そして正しいのは片方だけです。MeatPad が 63 MB と報告していたのと同じ瞬間、 ps は同じプロセスについて 147 MB と表示していました。

$ ps -o rss= -p $(pgrep -x MeatPad)
  150304

$ footprint -p $(pgrep -x MeatPad)
    phys_footprint: 63 MB
    phys_footprint_peak: 83 MB

レジデントセットサイズは、そのプロセスにマップされたすべてのページを数えます。AppKit、SwiftUI、CoreText などシステム側の、共有された読み取り専用のコピーオンライトのページも含みます。これらのページは Mac 全体で一度だけ常駐し、誰の負担にもなっていません。物理フットプリントは、そのプロセスが本当に責任を持つ分だけを数えます。アクティビティモニタのメモリ列に出るのもこの数字です。ネイティブの Mac アプリのメモリ量を誰かが挙げていたら、どちらを測ったのか尋ねてください。

理由その 1: プロセスの中にブラウザがない

MeatPad はネイティブアプリケーションです。Swift、AppKit、SwiftUI で書かれ、自前のフレームワークパッケージを含めてソースは 92 ファイル、約 1 万 5 千 5 百行。Chromium も、JavaScript ランタイムも、Node プロセスも、プラグインホストも、バンドルに同梱した UI ツールキットの独自コピーもありません。

最初の 100 メガバイトの正体は、ほとんどこれだけです。Web スタックの上に作られたエディタは、仕事場にブラウザを連れて行かなければなりません。そしてブラウザは独自の考えを持ったオペレーティングシステムです。独自のレイアウトエンジン、独自のガベージコレクタ、ウィンドウごとのプロセス、あらゆるものの独自コピー。あなたのコードを 1 文字描く前に、その代金はすでに支払われています。ネイティブアプリは、レイアウトエンジンもテキストエンジンもツールキットもマシンから借ります。Finder のためにすでに読み込まれているものです。

理由その 2: エディタは見えている行だけを組む

エディタが静かに間違えるのはテキストレイアウトです。スクロールバーの高さを正しくするために、長い文書のすべての行を実際のフォントと幅で測るというのは、何かを表示する前に片づける仕事としては重すぎます。

MeatPad は TextKit 2 上の STTextView で描画します。Apple の現行のテキストスタックで、ビューポート単位で動きます。画面に出ている範囲とその少し先だけを組み、離れれば再び忘れます。ファイルを開くとは、読み込んで 1 画面分を描くことです。残りの文書のコストはそこまでスクロールしたときまで先送りされ、離れれば解放されます。

理由その 3: ノートはメモリ上のデータベースではなく、ディスク上のファイル

ノートはどれも普通のテキストファイルで、その隣に小さな JSON が置かれているだけです。アプリはワークスペースをメモリに読み込んで、その中に住み着いたりしません。テキストを保持しているのは実際に開いている書類だけで、ウィンドウを閉じれば返します。

同じ発想がプロジェクト機能にも通っています。

• ファイルツリーはまず 1 階層だけを浅く読み、ウィンドウを即座に描いてから、準備ができた時点で完全なツリーに差し替えます。
• プロジェクト全体検索は、検索のたびにディスクから並行してファイルを読みます。検索と検索のあいだに常駐する検索インデックスはありません。ディスクは速いし、あなたのプロジェクトはそこまで大きくないからです。
• 補完のインデックスはファイルの中身ではなく、ファイルごとの識別子の出現回数を保持し、4 メガバイトを超えるファイルは飛ばします。
• シンタックスハイライトは tree-sitter です。C で書かれた小さなパーサで、開いている書類ごとに 1 本の構文木を持ち、入力のたびに作り直すのではなく差分で更新します。

理由その 4: 高価な知能は別プロセスに住んでいる

エディタの知能は本当に高価です。言語サーバーはプロジェクト全体の意味モデルを保持します。大きな Rust や Swift のコードベースでは、そのモデルはエディタがテキストに対して行うことすべてを軽く上回ります。

MeatPad はその仕事を自分の中で抱えません。すでにあなたのマシンに入っているサーバー、SourceKit-LSP、rust-analyzer、Pyright と Language Server Protocol で話します。いずれも独立したプロセスで、プロジェクトを開くと起動し、閉じると終了します。意味モデルにかかるコストはそのサーバーの側に計上され、アクティビティモニタにはサーバー自身の名前で表示され、プロジェクトを閉じた瞬間に返却されます。エディタが持つのはメッセージであって、モデルではありません。サーバーが入っていない場合、補完は開いているプロジェクトの識別子にフォールバックし、それ以外はそのまま動きます。

上の数字が都合のよい数字ではなく正直な数字だと言えるのも、このためです。機能を削って別プロセスに押し出し、見えなくしたから低いのではありません。大量のメモリを必要とする部分が、自分のメモリを持つことを許されているから低いのです。

この設計が牙をむくところ

表の 3 行目は誤植ではありません。6.3 MB のテキストファイルを 1 つ、行数にして約 12 万 9 千行を開くと、MeatPad は 1 ギガバイトを超え、CPU コアを 1 つ使い切ります。

原因はテキストエンジンではありません。そちらは宣伝どおりに動いています。原因はステータスバーです。ステータスバーは書類の行数、単語数、文字数を表示しますが、インターフェイスがレイアウトされるたびにテキスト全体をたどって 3 つとも計算し直します。ノートやソースファイルなら数キロバイトの走査で、誰も気づきません。12 万 9 千行では、レイアウトのたびに 6 メガバイトのテキストを丸ごとたどることになり、インターフェイスは実に頻繁にレイアウトされます。

修正は小さなものです。描画のたびではなく、テキストが変わったときに 1 度だけ数えればよいというだけで、すでに順番待ちに入っています。これを省かずここに書いているのは、良い測定値だけを並べたメモリの記事は広告だからです。エディタが実際に向けられる日常のファイルは、最初の 2 行の範囲に収まります。非常に大きな単一ファイルは未踏の領域で、それを直すのは私たちの仕事です。

なぜこれが午後 1 回分の価値があるのか

売れている Mac の多くはメモリが 16 GB で、1 ギガバイトを余らせている人はほとんどいません。ブラウザには 30 個のタブ、デザインツールは開きっぱなし、何かがビルド中。エディタが抱えたメモリは、コンパイラが使えないメモリです。そして足りなくなると macOS は圧縮とスワップを始め、それはすべてが同時に少しずつ悪くなる感覚として現れます。

システムのフレームワークを借り、見えている部分だけを組み、書類をファイルのまま置き、言語サーバーを別プロセスで走らせるネイティブアプリは、誰も最適化らしい最適化をしなくても 63 MB あたりに落ち着きます。これは英雄的なエンジニアリングの話ではありません。最初にブラウザを作らなかったことの、ごく当たり前の結果です。