Visual Studio “15” の全体的な応答性を向上

  • Article
本記事は、マイクロソフト本社の The Visual Studio Blog の記事を抄訳したものです。【元記事】 Improved overall Visual Studio “15” Responsiveness 2016/10/14

 

今回の記事は、Visual Studio “15” のパフォーマンス強化について 5 回にわたってお伝えするシリーズ記事の最終回です。

このシリーズでは下記の内容についてお伝えしてきました。

今回の記事では、Preview 5 に実装された機能強化のうち、Visual Studio を日常的に使用する際の応答性の向上を目的とするものをご紹介します。以下のセクションでは、デバッグのパフォーマンス向上、Git ソースの制御性の向上、XAML の編集エクスペリエンスの強化、拡張機能の管理による入力エクスペリエンスの強化について順番にご説明します。

デバッグ エクスペリエンスの高速化と編集中の応答性低下の防止

Visual Studio 2005 では、WPF、Windows フォーム、マネージ コンソール プロジェクトのホスティング プロセスが導入され、[Start Debugging] の応答を高速化するために、次回のデバッグ セッションで使用可能なプロセスをバックグラウンドで起動していました。しかし、この機能を導入した結果、[Stop Debugging] をクリックしたり、デバッグ セッションの終了後に Visual Studio を使用した場合に、Visual Studio が一時的に応答しなくなる問題が発生しました。

Preview 5 では、ホスティング プロセスを無効にして [Start Debugging] を最適化しました。これにより、ホスティング プロセスを使用しなくても従来の高速性が維持されるほか、以前からホスティング プロセスを使用していなかった ASP.NET、Universal Windows、C++ プロジェクトの場合はさらに高速になります。下記のグラフは、テスト マシンでサンプルの UWP 写真共有アプリ (英語)、素数の可視化を実行する C++ アプリ、簡単な WPF アプリの 3 つの起動時間を測定した結果です。

この機能強化を実現するために、[Start Debugging] を選択して [Diagnostic Tools] ウィンドウと IntelliTrace (既定でデバッグ セッションの開始時に毎回表示される) を初期化する場合のコストを最適化しました。IntelliTrace の初期化方法が変更され、デバッガーの他の処理やアプリケーションの起動と並列して初期化できるようになりました。また、ブレークポイントで停止した場合の IntelliTrace ロガーと Visual Studio プロセスの通信方法も効率化されました。

このほか、[Diagnostic Tools] ウィンドウに関連するバッググラウンド スレッドが Visual Studio のメイン UI スレッドのコードを同期的に実行する必要があった箇所も修正しました。これにより、ETW イベント コレクション内の非同期イベントの割合が増加し、デバッグ セッションを再開する場合に ETW セッションが終了するまで待機する必要がなくなりました。

Git.exe によるソース コードの操作の高速化

Visual Studio に Git のサポートが追加された時点では、libgit2 というライブラリが使用されていました。しかし、libgit2 とコマンド プロンプトから使用する git.exe は機能が異なるほか、libgit2 を使用すると Visual Studio のメイン プロセスに対して数百 MB のメモリ負荷が発生するという問題がありました。

Preview 5 では、この libgit2 の実装を廃止して、代わりに git.exe をプロセス外から呼び出すようにしました。そのため、Git がマシン上のメモリを消費することには変わりないものの、VS のメイン プロセスに対してメモリ負荷は発生することはなくなりました。また、git.exe を使用することで Git 操作が段階的に高速化することも期待されます。現時点では、大規模なリポジトリに対して git clone コマンドを実行した場合に処理が高速化したことを確認しています。テスト用マシンで Roslyn .NET Compiler リポジトリのクローンを作成したところ、Visual Studio 2015 では 5 分 40 秒かかったのに対し、Visual Studio “15” では所要時間が 4 分と、30% の短縮になりました。以下の動画はそのようすを示したものです (4 倍速で再生しています)。

今後のリリースでは、この新しいアーキテクチャによって他の操作も高速化される予定です。

また、Git の使用について特に多くのご不満が寄せられていたのが、コマンド ラインからブランチを切り替えた場合に Visual Studio がソリューション内のすべてのプロジェクトを 1 つずつ読み込み直すという問題です。この問題も修正され、ファイル変更の通知ダイアログの [Reload All] が [Reload Solution] に変更されました。

これにより、ソリューションの再読み込みが非同期で 1 回のみ実行され、個々のプロジェクトを再読み込みする場合よりもはるかに短時間で処理が終了します。

XAML のタブ切り替えの高速化

データやお客様からのフィードバックによると、開発者の 25% が 1 日に 1 回以上は XAML のタブを切り替えるときに 1 秒以上の遅延を経験しています。さらなる調査の結果、この遅延はマークアップ コンパイラが原因であることが判明しました。そこで、XAML 言語サービスを利用することで、タブの切り替えを大幅に高速化しました。以下の動画で、この機能強化の成果をご確認ください。

マークアップ コンパイラは各 XAML ファイルの g.i.* ファイルを作成します。このファイルには XAML ファイル内の名前を持つ要素を表すフィールドが含まれていて、名前を持つ要素をコードビハインドから参照する場合に使用できます。たとえば、<Button x:Name=”myButton” /> という要素が存在する場合、g.i.* ファイルには Button 型の名前を持つボタンのフィールドが含まれ、コード内で “myButton” を使用することができます。

XAML ファイルを保存したり、保存されていない XAML ファイルから他のファイルに切り替えたりすると、分離コード ファイルを開いた場合に IntelliSense が最新の名前を持つ要素を表示できるように、Visual Studio がこの g.i.* ファイルを更新します。従来のリリースでは、この g.i.* ファイルの更新は毎回マークアップ コンパイラが実行していました。マネージ プロジェクト (C#/VB) では、マークアップ コンパイラが UI スレッドで実行されていたため、複雑なプロジェクトでタブを切り替えると目に見える遅延が発生していました。

Preview 5 ではこの問題が修正され、XAML 言語サービスが保持している XAML ファイルの情報を利用して IntelliSense に表示するフィールドの名前と型を判別してから、バックグラウンド スレッドで Roslyn を使用して g.i.* ファイルを更新するようになりました。言語サービスでは、コンパイラの速度低下の原因となる解析や型メタデータの読み込みをすべて完了しているため、マークアップ コンパイラを実行する場合よりもはるかに高速です。ただし、g.i.* ファイルが存在しない場合 (XAML ファイルの名前を変更した場合やプロジェクトの obj ディレクトリを削除した場合) は、マークアップ コンパイラを実行して g.i.* ファイルを最初から生成し直す必要があるため、これまでと同様に遅延が発生します。

XAML の入力エクスペリエンスの応答性向上

XAML 言語サービスで UI の遅延が発生する主な原因は、初期化、メタデータの変更への対応、デザイン アセンブリの読み込みです。今回のバージョンでは、処理をバックグラウンド スレッドに移動することで、これら 3 つの原因をすべて解消しました。

デザイン アセンブリ メタデータの読み込みについては、下記の機能強化も実施されました。

  • デザイン アセンブリ メタデータのシリアル化層が新たに追加され、境界を越える呼び出しが大幅に減少しました。
  • WPF プロジェクトでデザイナーのアセンブリ シャドウ キャッシュが再利用されるようになりました。また、すべての種類のプロジェクトでシャドウ キャッシュがセッション間で再利用されるようになりました。従来、これらのシャドウ キャッシュはメタデータが変更されるたびに作成し直されていました。
  • メタデータが変更されるたびに再計算されていたデザイン アセンブリ メタデータが、セッション期間中はキャッシュされるようになりました。

これらの変更により、ソリューションの読み込みが完全に完了する前に XAML の IntelliSense を使用できるようになりました。

入力時の応答性低下の原因となっている拡張機能の特定

入力時の応答性低下については、多数のご報告をいただいています。現在これらの不具合の修正を進めていますが、この応答性低下の原因の大半はキーボードの操作中にコードを実行する拡張機能です。このような原因を確認できるように、[Help]、[Manage Visual Studio Performance] からレポートにアクセスできるようになったほか、入力エクスペリエンスに影響を与えている拡張機能を通知する機能が追加されました。

入力の応答性低下の原因となっている拡張機能の通知

[Help]、[Manage Visual Studio Performance] の順に選択すると拡張機能の詳細が表示されます。

試用と問題のご報告のお願い

今回の記事では Preview 5 に実装された機能強化の一部をご紹介しました。マイクロソフトは、今後も Visual Studio の応答性の向上に向けた取り組みを継続してまいります。皆様が最も必要とする機能に重点的に取り組むことができるように、ぜひ Visual Studio “15” Preview 5 をダウンロードしてご試用いただき、[Report-a-Problem] ツール (英語) から機能強化に関するご提案をお寄せください。

Dan Taylor (シニア プログラム マネージャー)Dan Taylor は、5 年前にマイクロソフトに入社して以来、.NET と Visual Studio のパフォーマンス強化に取り組んでいるほか、Visual Studio と Azure のプロファイリングおよび診断ツールを担当しています。