デマンドページング
例えば，VirtualAlloc で 256MB のメモリを確保し，先頭から何か書き込んでいくというプログラムで実験してみましょう．
VirtualAlloc ( NULL, 1024 * 1024 * 256, MEM_COMMIT, PAGE_READWRITE );
各時点での値は，以下のようになります．
| Page Faults | Working Set [KB] | Private Bytes [KB] | Virtual Size [KB] | |
|---|---|---|---|---|
| 1. 起動直後 | 304 | 1,232 | 292 | 7,780 |
| 2. VirtualAlloc直後 | 304 | 1,232 | 262,692 | 269,924 |
| 3. 128MBまで書き込み | 33,105 | 132,564 | 262,692 | 269,924 |
| 4. 256MBまで書き込み | 65,907 | 263,900 | 262,692 | 269,924 |
| 5. ウィンドウ最小化 | 65,912 | 328 | 262,692 | 269,924 |
VirtualAlloc の直後に増えているのは "Private Bytes" であって，実際にアクセスするまでは "Working Set" は増えていないというのがポイントですね．これが示しているのは，実際にメモリアクセスが行われるまでは物理メモリの割り当てが遅延されていることです*1．また，id:NyaRuRu:20050607:p1 でも紹介したように，ウィンドウ最小化すると "Working Set" が減少しています．これは，ウィンドウ操作に関するヒューリスティックに基づいた最適化と言えるでしょう．
このように "Working Set" は物理メモリの占有量と密接な関係は確かにあるのですが，メモリのアクセスパターンや他のアプリケーションの物理メモリ使用具合などを元に OS が決定する数字であるため，プログラムのメモリアルゴリズムを推測するのには不向きです．そして Windows 標準のタスクマネージャがプロセスごとの「メモリ使用量」として表示しているのは "Private Bytes" (修正:"Working Set") の値の方なのです．
例えば，/.J で Firefox の「メモリ使用量」に関する FAQ としてしばしば紹介されている blog エントリには，こんなことが書いてあります．
オレはもともとの値だった 4MB (4096) で試してみたが、特に問題もないしメモリの使用量もだいたい 50〜60MB前後のところから増えることがなくなった。(一時的に増えたときは、ウインドウを最小化すると一気に解放してくれる)。
これは恐らく "Working Set" の値を見ておられるのだと思いますが，実際これは Firefox のメモリ空間の内どれだけ物理メモリに残すかという OS 側の目標値が減少しただけで，(追記:最小化時には) Firefox はメモリの解放どころか何もしていないと考えられます．
(修正:FireFox→Firefox，thanks to Firefox スレの人)
*1:『インサイドMicrosoft Windows (上)』7.9.1 デマンドページング
