MailVaultはWindowsでどれくらいメモリを使いますか？実際に測定しました

MailVault 2.16は、Windowsで動作する最初のバージョンです。新しいデスクトップアプリ、特にWebベースのインターフェースを持つアプリについて誰もがまず尋ねる質問は、どれくらいメモリを使うのかということです。そこで、Macですでに使っているのと同じテスト用メールボックスを使い、同じメモリテストをWindows 11のノートパソコンで実行して、すべての数値を記録しました。

手短に言うと、起動時は約210 MB、10,000 通の受信トレイを読み込んだ状態でも約210 MB、その大きな受信トレイを開く数秒間は365 MB近くまで上がり、同期を担うバックグラウンドヘルパーは約23 MBです。

テストの内容

このテストでは、ローカルのテスト用メールサーバー上に2つのメールアカウントを用意します。受信トレイに58 通のものと、10,000 通のものです。自動実行が、人が操作するのと同じように実際のアプリを動かします。MailVaultを開き、小さいほうの受信トレイを開いてから、大きいほうのアカウントに切り替え、10,000 通すべてのメッセージヘッダーが一覧に表示されるまで待ちます。一覧全体を先頭から末尾までスクロールしたあと、アプリを10分間放置します。各段階で、MailVaultが所有するすべてのプロセスのメモリを記録します。

使用したノートパソコンはMSI製で、Intel Core i7-13620Hとメモリ16 GBを搭載し、Windows 11 23H2を電源に接続した状態で動かしました。まっさらな環境ではなく、MailVaultのもう1つのコピーを含む他のアプリも開いていたため、普段どおりの、忙しいコンピューターでの結果と考えてください。テスト全体を、毎回新しい空のプロファイルで3回実行し、以下の数値はその3回の実行の範囲です。ビルドはMailVault 2.16の最適化されたリリースビルドにテスト用のフックを有効にしたもので、配布版とほぼ同じですが、バイト単位で完全に同一ではありません。

MailVaultのメモリとして数えるもの

Windows版のMailVaultは1つのプロセスではないため、「MailVault」という名前のプロセスだけを足し合わせると、メモリの大部分を見落としてしまいます。構成は次の3つの部分です。

• アプリウィンドウ（mailvault.exe）：ウィンドウ、メニュー、Windowsとの連携部分です。
• バックグラウンドヘルパー（mailvault-daemon.exe）：同期、メッセージの保管庫への保存、検索インデックス、バックアップを担当します。ウィンドウを閉じても動作を続けるので、予約したバックアップもそのまま実行されます。
• Microsoft Edge WebView2（msedgewebview2.exeの複数のプロセス）：画面を描画するエンジンです。Windowsの一部なので、MailVaultは独自のブラウザを同梱していません。レンダラー、GPUプロセス、ブラウザプロセス、そして小さなネットワークとストレージのヘルパーに処理を分割しています。

私たちは、これらすべてを数えます。ただし、起動したMailVaultに属するものだけです。使用する数値は、タスク マネージャーの「メモリ」列に表示される値、つまりプライベートワーキングセット（そのプロセスだけが持ち、いま実際にRAM上にあるメモリ）です。EdgeなどほかのアプリとWebView2が共有するプログラムコードのような、共有ページは数えません。

結果

Windows 11 · Intel i7-13620H · 16 GB · 3 runs · all MailVault processes

moment                           Task Manager    commit size
launch, 58 messages              209 – 224 MB    297 – 298 MB
10,000 messages loaded           197 – 218 MB    297 – 302 MB
peak while opening 10,000        357 – 367 MB    545 – 560 MB
after scrolling all 10,000       234 – 252 MB    355 – 356 MB
after ten minutes idle           102 – 122 MB    308 – 318 MB

background helper, 10,000 msgs    22 – 23 MB
app window                        11 – 13 MB

2列目はコミット サイズです。各プロセスが予約しているプライベートメモリで、いまRAM上にあるかどうかは問いません。これは最初の実行のあとに追加したため、3回ではなく2回分の実行をカバーしています。これが効いてくるのが最後の行です。数分間操作がないと、Windowsは使われていないプロセスからメモリを取り上げ、タスク マネージャーの数値は約110 MBまで下がります。このメモリはMailVaultが解放したのではなくWindowsが取り置いているだけで、コミット サイズを見ると、戻ってきたときに取り戻せる約310 MBをアプリがまだ保持していることが分かります。Windows上でのMailVaultのコストを1つの数値で言うなら、大きなメールボックスがある場合でおよそ300 MBという数値を使ってください。

メモリの内訳

10,000 通を読み込んだ状態では、メモリのおよそ5分の4は、画面を描画するWebView2が占めています。本当にMailVault自身のコードにあたる部分、つまりアプリウィンドウとバックグラウンドヘルパーを合わせると、約35 MBです。

• 画面を描画するWebView2レンダラー：86 MB
• WebView2のGPUプロセス：51 MB
• WebView2のブラウザ・ネットワーク・ストレージのプロセス：37 MB
• バックグラウンドヘルパー：23 MB
• アプリウィンドウ：12 MB

バックグラウンドヘルパーが小さいのは、メールをメモリ上に保持しないためです。メッセージとヘッダーキャッシュはディスク上のファイルと小さなデータベースに置かれており、ヘルパーは要求されたときにそれらを読み込みます。起動時の8 MBから、10,000件のヘッダーを同期したあとは23 MBまで増えました。10分間静かにしていたあと、タスク マネージャーの数値は10 MBまで戻りましたが、コミット サイズは25 MB前後のままでした。この低下はWindowsがメモリをトリミングした結果であり、ヘルパーがメモリを手放したわけではありません。

大きなメールボックスを開く

メモリが跳ね上がる唯一の瞬間は、大きなアカウントを初めて開いたときです。MailVaultは、そのメールボックスのキャッシュ済みヘッダーをすべて一度に一覧へ読み込みます。そうすることで、並べ替えや件数、フィルターが、スクロールし終えた部分だけでなくメールボックス全体に対して機能します。レンダラーはその一覧を作る間だけ一時的におよそ2倍になり、そのあとほとんどのメモリを解放します。

同じピークをMacでも計測し、メールボックスを小さく分けて読み込むことでなくそうとしました。しかし効果はなく、ピークは変わりませんでした。これをなくすには一覧がメッセージを保持する方法そのものを変える必要があり、それは今後の課題ですが今回のリリースには含まれていません。

WindowsとMacを並べてみる

Windowsでの実行より4日前の9月22日に、メモリ16 GBのApple M4 Mac miniで同じテストを実行しました。合計は起動時とピーク時では近い値になります。Windowsは、大きなメールボックスを読み込んだ状態ではやや少なく、アイドル時は上で説明したトリミングのためにかなり少なくなります。

起動時、58 通
Windows、タスク マネージャーのメモリ209–224 MB
Windows、コミット サイズ297–298 MB
Mac、アクティビティモニタのメモリ180 MB
10,000 通を読み込んだ状態
Windows、タスク マネージャーのメモリ197–218 MB
Windows、コミット サイズ297–302 MB
Mac、アクティビティモニタのメモリ315–324 MB
10,000 通を開く際のピーク
Windows、タスク マネージャーのメモリ357–367 MB
Windows、コミット サイズ545–560 MB
Mac、アクティビティモニタのメモリ368–380 MB
10分間アイドル状態のあと
Windows、タスク マネージャーのメモリ102–122 MB
Windows、コミット サイズ308–318 MB
Mac、アクティビティモニタのメモリ234–263 MB

これは競争ではなく、2つの測定値を並べたものとして読んでください。2つのシステムはメモリの数え方が異なります。Macのアクティビティモニタの数値には、macOSが圧縮したメモリが含まれる一方、タスク マネージャーの数値はWindowsがトリミングしたメモリを含みません。また、コミット サイズは予約されただけで一度も使われていないかもしれないメモリまで数えます。マシンも異なりますし、Mac側のビルドは4日古いものでした。この比較が示しているのは、MailVaultがどちらのシステムでも数百メガバイトの下のほうという同程度のメモリしかかからないこと、そしてどちらのシステムでも、観察した10分間のアイドル状態の間にメモリが増えることはなかったということです。

このテストでわからないこと

• 実際のメッセージはもっと大きくなります。テストメッセージは小さいため、開いたメッセージのキャッシュが埋まることはありませんでした。実際に多くのメールを読むと、キャッシュの上限である128 MBまで追加でかかることがあります。
• 10日間ではなく10分間です。このアイドルテストは、速いメモリリークを検出できる長さであり、遅いものまでは検出できません。より長いテストは次の課題です。
• ノートパソコン1台とMac1台だけです。グラフィックチップやWindowsのバージョンが違えば、合計の大部分を占めるWebView2の数値は変わり得ます。

このテストは自分でも再現できます。MailVaultのソースにあるram-footprintというエンドツーエンドテストで、wdio.ram.conf.jsで実行し、すべての測定値をプロセスごとにJSONファイルへ書き出します。

測定日はWindowsが2026年9月26日、macOSが2026年9月22日です。関連記事：50,000 通のメールをミリ秒で検索。