読者です 読者をやめる 読者になる 読者になる

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

.NET

上の環境に『Microsoft© Visual Studio© 2005 Service Pack 1』入れてみたのですが,確かに以下の言及が必要であると頷けるほどの所要時間と GB 規模の Disk I/O でした.結局インストールにかかった時間は 1 時間ぐらい.

注意事項

  1. インストールにかかる時間:
    • Visual Studio© 2005 SP1 などの大容量の Service Pack の場合、セットアップの要件によりインストールに長時間かかることがあります。インストールにかかる時間は、コンピュータの機能と、更新される Visual Studio© 2005 製品の個数によって異なります。
    • ユーザー アカウント制御 (UAC) を有効にして Windows Vista™ にインストールすると、最初のセットアップ ダイアログ ボックスが表示されるまでにかなり時間がかかることがあります。ダイアログ ボックスが表示されるまでの間、UAC 機能によってインストール パッケージのデジタル署名が確認されています。この Service Pack によって多数のファイルがインストールされるため、場合によってはインストールに 1 時間かかることもあります。
  2. インストール要件:
    • サポートされている 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:これは確認しようと思えば確認できるかな