『3 分ぐらいでわかる，Process Explorer による Windows Vista メモリ使用状況の調べ方 - NyaRuRuの日記』実践編．
軽く見てみただけですが，だいぶ収穫ありました．
メモリ管理テクノロジの Windows SuperFetch は、Windows ベース PC で今までの使用パターンに基づいてメモリの内容を最適な状態に維持し、特定の時間にシステム メモリの内容がどのような状態になっているべきかを Windows Vista がインテリジェントに判断できるようにします。また、Windows Vista で、優先度の高い内容をメモリの外に排除してしまうような、問題のあるメモリの使用パターンを検出して回避できます。
Process Explorer で実験してみたところ，以下のような特徴が見えてきました．
Standby List の優先度と用途
SuperFetch 等で先読みされるファイル内容は，Standby List の優先度 4 以下に集中している模様．一方，ワーキングセットから除外されてページファイルとの同期が完了した領域は，Standby List 優先度 5 の増加として見えました．ちなみに数字が小さいほど優先度が低いことを意味します．これによってワーキングセットから除外された内容がメモリにとどまりやすくなっているようです．
「Windows Vista でどれぐらいファイル内容が (先読み) キャッシュされているか？」を知りたければ，Standby List の優先度 4 以下あたりを眺めると良さそうです．
(追記)優先度についてはだいぶ分かってきたのそのうちまとめます．
アフターランチシンドロームの回避
しかし，実はここに少し問題がある。「アフター・ランチ・シンドローム」とでも呼ぶべき現象だ。これは，作業の途中で昼食などでしばらく席を空ける間に，ウイルス・チェックやディスクのデフラグなどのプロセスがメモリーを大量に使用して，それ以前に使用していたプロセスのメモリーを，みんなページング・ファイルに追い出してしまうというものだ。その結果，昼食から戻って来て作業の続きをしようとすると，ページング・ファイルからの読み戻しが発生して，一時的にパフォーマンスが下がってしまう。
Windows Vistaでは，この問題を解決するために，新たに「SuperFetch」という仕組みを導入している。これは，アプリケーションの挙動を監視して，優先度の高いコードやデータを推定し，物理ページにあらかじめロードしておくという機能で，システムのサービスとして実装されている。これにより，昼食後のパフォーマンス低下をある程度防ぐことができるが，SuperFetchで使われるぶん，必要な物理メモリー量も増加する。搭載物理メモリーが少ない場合には，かえってパフォーマンスの低下をもたらすこともあるので注意が必要だ。SuperFetch機能をオフにするには，コントロール・パネルからSuperFetchのサービスを停止すればよい。
この動作も確認できました．
「アフター・ランチ・シンドローム」をエミュレートするために，900 MB のメモリを確保し，確保した領域を適当な内容で埋め，メモリを解放するという実験をしてみました．以下はその間の Standby Lists の変化です．
| Paging Lists 表示値 | 初期状態 | →900 MBメモリ確保 + memset 直後 | →メモリ解放後しばらく放置 |
|---|---|---|---|
| 優先度 0 | 0 MB | 0 MB | 0 MB |
| 優先度 1 | 1 MB | 0 MB | 215 MB |
| 優先度 2 | 46 MB | 1 MB | 288 MB |
| 優先度 3 | 333 MB | 1 MB | 99 MB |
| 優先度 4 | 224 MB | 10 MB | 66 MB |
| 優先度 5 | 225 MB | 84 MB | 278 MB |
| 優先度 6 | 4 MB | 5 MB | 5 MB |
| 優先度 7 | 16 MB | 19 MB | 19 MB |
| - | - | - | |
| Standby Lists 合計 | 880 MB | 120 MB | 973 MB |
memset 直後は，優先度の数字が小さい領域から Standby Lists が切り崩されています．そしてメモリ解放後しばらく放置すると，Standby Lists の内容が復元しています．復元順序にも特徴があって，優先度の数字が大きなものから順に再読込が行われていました．
特筆すべきは，いわゆる「ページアウト」に関連する優先度 5 のサイズがほぼ同じにまで回復していることでしょう．これにより，「ランチ前」のアプリケーション使用状態はかなり再現されることになります．
"No more 昼食後に Visual Studio が派手にページアウトされていてげんなり体験！"
また，より優先度の数字の小さな領域は，元の配分を再現するわけではなく，その時点での再配分が行われているようです．
ReadyBoost
上記 Standby Lists 復元時にもうひとつ気付いたことは，このとき ReadyBoost のヒット率が非常に高い値をキープしていたことです．これは考えてみれば結構なるほどな話．今 Standby Lists に存在する内容は，一時的にパージしたとしても，後で読み直す可能性が高そうです．ということは Standby Lists に存在する内容が，高確率で ReadyBoost キャッシュにも存在するようにしておけばよくて，実際パージ後のリカバー速度向上に効いてくると．
大容量メモリ搭載時に ReadyBoost が全く役に立たないかというと，実際は特定局面でそれなりに活躍しているのかもしれませんね．体感速度の向上という形では実感しにくいかもしれませんが．
