今日は、
Visual Studioプロファイリングツールを使用してアプリケーションのパフォーマンスを測定します。
Visual Studioプロファイリングツールを使用すると、開発者はアプリケーションとコードのパフォーマンスを測定および評価できます。 これらのツールはIDEに完全に統合されており、開発者に中断のない制御を提供します。
このガイドでは、
Sampling and
Instrumentationプロファイリングメソッドを使用して
PeopleTraxアプリケーションのプロファイルを作成し、アプリケーションパフォーマンスの問題を特定します。

たくさんの写真。
準備する
このガイドを使用するには、次のものが必要です。
- Microsoft Visual Studio 2010
- C#の平均的な知識
- PeopleTraxテストアプリケーションのコピーは、 MSDNコードギャラリーからダウンロードできます。
プロファイリング方法
この記事のメイントピックから少し戻って、可能なプロファイリング方法を考えてみましょう。 この章はスキップできます。使用するプロファイリング方法については、使用前に簡単に説明します。
サンプリング
サンプリング -アプリケーションの操作に関する統計を収集します(プロファイリング中)。 この方法は軽量であるため、作業の結果として、取得されたデータに非常に小さなエラーがあります。
特定の時間間隔ごとに、コールスタック(コールスタック)に関する情報が収集されます。 このデータに基づいて、パフォーマンスが計算されます。 初期プロファイリングおよびCPU使用率に関連する問題の識別に使用されます。
計装
計装 -呼び出された各機能の動作時間に関する詳細情報を収集します。 I / O操作のパフォーマンスを測定するために使用されます。
このメソッドは、コードをバイナリファイルに埋め込みます。このファイルには、ファイル内の各関数と、この関数で呼び出される各関数の同期(時間)に関する情報が記録されます。
レポートには、費やされた時間を表す4つの値が含まれています。
- 経過包括 -関数の実行に費やされた合計時間
- Application Inclusive-オペレーティングシステムへのアクセスにかかる時間を除き、関数の実行にかかる時間。
- Elapsed Exclusive-本体でコードの実行に費やした時間。 ターゲット関数によって呼び出された関数が費やす時間。
- 排他的アプリケーション -本体のコードの実行にかかった時間。 オペレーティングシステムへの呼び出しに費やされた時間と、ターゲット機能によって引き起こされた機能を完了するのにかかった時間は含まれません。
並行性
同時実行性 -マルチスレッドアプリケーションに関する情報を収集します(マルチスレッドアプリケーションのデバッグ方法については、
「Visual Studio 2010デバッグマルチスレッドアプリケーションガイド」を参照してください) このメソッドは、競合するスレッドがリソースへのアクセスを待機するたびに、コールスタックに関する詳細情報を収集します。
.NETメモリ
.NETメモリ -プロファイラーは、ディストリビューションで作成されたオブジェクトまたはガベージコレクターによって破棄されたオブジェクトのタイプ、サイズ、および数に関する情報を収集します。 メモリプロファイリングは、アプリケーション全体のパフォーマンスにはほとんど影響しません。
層の相互作用
層の相互作用 -ASP.NETページまたは他のアプリケーションと
SQLサーバー間の同期
ADO.NET呼び出しに関するプロファイル用の情報をファイルに追加します。 データには、呼び出しの回数と時間、最大時間と最小時間が含まれます。
プロファイリング方法のこの説明を終了し、アプリケーションのプロファイル方法を引き続き学習します。
プロファイリングのサンプリング方法
サンプリングは、問題のプロセスを定期的にポーリングしてアクティブな機能を決定するプロファイリングメソッドです。 結果は、テスト中にコールスタックの先頭に関数があった回数を示します。
プロファイリング
テストプロジェクト
PeopleTraxを開きます。
リリースで構成を設定します(アプリケーションをデバッグするための追加バージョンがデバッグバージョンに組み込まれており、プロファイリング結果の精度に悪影響を及ぼします)。
[
分析 ]メニューで、[
パフォーマンスウィザードの
起動 ]をクリックします。

このステップでは、プロファイリング方法を選択する必要があります。 [CPUサンプリング(推奨)]を選択し、[次へ]をクリックします。

プロファイルするアプリケーションを選択します。これは
PeopleTraxと[次へ]ボタンです。 次に[完了]をクリックすると、プロファイラーとアプリケーションが自動的に起動します。 画面にPeopleTraxプログラムが表示されます。
Get Peopleボタンを押し、作業の完了と
データのエクスポートを待ちます。 メモ帳とプログラムを閉じると、プロファイラーがレポートを生成します。

プロファイラーが生成したレポート(* .vsp)

サンプリング方法レポート分析
概要には、プロファイリング時間全体にわたるプロセッサー使用率のグラフが表示されます。
ホットパスリストには、最もアクティブなコールブランチが表示されます。 そして、
ほとんどの個々の作業を行う関数のリスト(その名前はそれ自体を物語っています)-これらの関数の本体でプロセスの大部分を占める関数。
ホットパスリストを見ると、
PeopleNS.People.GetNamesメソッドが呼び出しブランチのほぼ最後の場所を
占めていることが
わかります。 その後、パフォーマンスを改善するために、より慎重に調査できます。
PeopleNS.People.GetNamesをクリックすると、
関数の詳細が表示されます。

このウィンドウには2つの部分があります。 経費ウィンドウは、機能の操作、および選択されたインスタンスの数に対する機能とその呼び出し元の寄与のグラフィカルな表現を提供します。 問題の機能を変更するには、マウスでクリックします。
関数コードビューは、使用可能な場合はメソッドのコードを表示し、選択したメソッドで最も「高価な」行を強調表示します。
GetNamesメソッドを選択すると、
StringReaderを使用してアプリケーションリソースから行を読み取り、各行を
ArrayListに追加することが
わかります。 この部分を改善する明確な方法はありません。
PeopleNS.People.GetPeopleのみが
GetNamesを呼び出す
ため 、
GetPeopleをクリックします。 このメソッドは、
GetNamesメソッドによって返された人と会社の名前を持つ
PersonInformationNS.PersonInformationオブジェクトの
ArrayListを返します。 ただし、
GetNamesは
PersonInformationが作成されるたびに2回呼び出されます。 (これは黄色と赤の強調表示で示されます)。 明らかに、メソッドの最初に一度だけリストを作成することにより、メソッドを簡単に最適化できます。
GetPeopleの代替バージョンもコードに含まれており、今すぐ
有効にします。 これを行うには、
Peopleおよび
PeopleTraxのプロジェクトプロパティウィンドウで、
OPTIMIZED_GETPEOPLEを条件付きコンパイルシンボルとして定義し
ます 。
はい、私の実験を繰り返したい場合は、プロジェクトのエラーを修正する必要があります。 リソースの名前は、クラスの最適化されたコンストラクターで正しくつづられていません。PeopleNS.ResourcesとPeopleNS.Resourceが必要です。 これを変更しないと、すべてがひどい間違いで失敗します。
最適化された方法は、次のビルドで古い方法を置き換えます。
Performance Explorerウィンドウで「
プロファイリングで
起動」をクリックして、現在のセッションでプロファイリングを再開します。 [ユーザーを
取得して
データを
エクスポート]をクリックします。 ノートブックとプログラムを閉じると、プロファイラーは新しいレポートを生成します。

2つのレポートを比較するには、両方とRMB
Compare Performance Reportsを選択します。 デルタ列は、
ベースラインバージョンと後の
比較のパフォーマンスの違いを示しています。
Inclusive Samples%を選択して適用します。
ご覧のとおり、パフォーマンスの向上は肉眼で確認できます。

計装プロファイリング
この方法は、入出力操作のプロファイリング、ディスクへの書き込み、およびネットワークを介したデータ交換の際に役立ちます。 この方法は、前の方法よりも多くの情報を提供しますが、オーバーヘッドが多くなります。 追加のコードを挿入した後に取得されたバイナリは通常よりも多く、展開用ではありません。
今回は、ユーザーのリストがノートブックファイルに書き込まれるデータエクスポートに分析を集中します。
プロファイリング
Performance Explorerで、 Instrumentationを選択し、Start Profilingをクリックします。 Get Peopleをクリックします。 人を読み込んだ後、10秒待って[データのエクスポート]をクリックします。 ノートブックとプログラムを閉じます。 プロファイラーはレポートを生成します。
分析
プロファイラーはこの写真を表示します:

必要な情報を受け取りませんでした。 データをフィルタリングします。 不要になったプロファイリングデータを単に除外するために、具体的には10秒待機しました。 13日から最後までマークを付けて、[
選択でフィルター ]をクリックします。 すでに別の結果:
ホットパスは、
Concatメソッドが時間がかかることを示しています(これは、最も個別の作業を伴う関数リストの最初のメソッドでもあります)。 [
連結]をクリックして、メソッドの詳細を表示します。
PeopleTrax.Form1.ExportDataが
Concatを呼び出す唯一のメソッドであることが
わかります。 呼び出し元のメソッドで
PeopleTrax.Form1.ExportDataをクリックします(
この関数を呼び出す関数 )。

コードウィンドウでメソッドを分析します。 Concatへの直接の呼び出しはないことに注意してください。 一緒に、オペランド
+ =の使用があり、コンパイラはこれをメソッド
System.String.Concatに置き換え
ます 。 ほとんどの人は、.NETで文字列を変更すると古いバージョンの文字列が破壊され、変更された文字列が作成されることを既に知っています。 幸いなことに、.NETには、このような作業のために設計された
StringBuilderクラスがあります。
プロジェクトには、すでに
StringBuilderを使用した最適化されたメソッドがあります。 PeopleTraxプロジェクトでは、コンパイル変数
OPTIMIZED_EXPORTDATAを追加し
ます 。 プロファイラーを保存して再度実行し、レポートを比較します。 Concat呼び出しを最適化したことはすぐに明白です(そして論理的に明確です)(6000から0回まで)。
アプリケーションを起動すると、目に見えるパフォーマンスの改善が目に見えます。 プロファイリングを再度実行することは非常に重要です。目に見える改善もあります。 問題を修正した後に新しいデータを表示すると、アプリケーションのパフォーマンスに関する他の問題が明らかになる場合があります。
文学
ご清聴ありがとうございました。 コードを稲妻のように素早く。