Microsoft© Visual Studio© 2005 Service Pack 1 と Transactional File Update のスケーラビリティ

Visual Studio 2005 Team Suite
Visual C# 2005 Express Edition
Windows XP SP2

注意事項

インストールにかかる時間:

Visual Studio© 2005 SP1 などの大容量の Service Pack の場合、セットアップの要件によりインストールに長時間かかることがあります。インストールにかかる時間は、コンピュータの機能と、更新される Visual Studio© 2005 製品の個数によって異なります。

ユーザーアカウント制御 (UAC) を有効にして Windows Vista™ にインストールすると、最初のセットアップダイアログボックスが表示されるまでにかなり時間がかかることがあります。ダイアログボックスが表示されるまでの間、UAC 機能によってインストールパッケージのデジタル署名が確認されています。この Service Pack によって多数のファイルがインストールされるため、場合によってはインストールに 1 時間かかることもあります。

インストール要件:

サポートされている Visual Studio© 2005 製品のコピーが対象のコンピュータにインストールされている必要があります。

Microsoft© Windows© Installer 3.1 以降がコンピュータにインストールされている必要があります。

192 MB の RAM が必要です。256 MB 以上が推奨されます。

最小ハードディスク容量: 6.2 GB

対象のコンピュータに複数の Visual Studio© 2005 製品がインストールされている場合、インストール要件の値が大きく増加することがあります。

ここまで来ると，例の「中身はとにかく結果が遅ければ何かヘマをやらかしているというのは分かる」規模だと思います．私はインストーラ関係は詳しくないので完全に印象論ですが，現状 Microsoft が実現できている Transactional File Update のスケーラビリティは GB 単位 (あるいは個数？) でほぼ限界に近いような印象を受けます．みなさんいかがでしょうか？ (とか書くと id:Tocchan がフォローしてくれる？)

MSI に限らず，各 OS でどのように大量のファイルを Transactional Update しているのかちょっと興味が出てきました．スケーラビリティという観点から考えてみると，例えば Transactional NTFS のようなファイルシステムベースの改良や，数 GB 単位の USB メモリ上で事前処理するといったアルゴリズムベースの改良など，素人考えでもまだまだ改良の余地はあるように思います．
必要リソースに関しては，要は Informed Consent だと思います．Fire File Copy のように，「大量に物理メモリを使用するが，結果的に大きくスループットが改善する方法がある．使用するか？」という形で提供されるなら，私は別にインストーラが 1 GB の物理メモリを使用しても腹は立ちません．むしろ，リソースが有効利用されていることを認識できることで，満足度は上がるのではないかと思います．
また，Vista UAC 環境下での注意事項も興味深いものがあります．実行ファイルのダブルクリック後，デジタル署名の確認のためファイル全体のハッシュ計算を行っているんじゃないかと予想していますが*1，その後やっとダイアログが表示されるというのは，ユーザビリティ上は明らかに失策と言えるでしょう．少なくとも「デジタル署名を確認しています」といった進捗表示やキャンセルボタンは表示させるべきでした．この辺り，私も Vista のベータテスト時にうすうす感じてはいたのですが，きちんとフィードバックを送っておくべきでしたね．ちょっと失敗でした．

*1:これは確認しようと思えば確認できるかな