プロファイリング（コンピュータプログラミング）

ソフトウェア エンジニアリングにおいて、プロファイリング(「プログラム プロファイリング」、「ソフトウェア プロファイリング」) は、たとえば、プログラムのスペース (メモリ) や時間の複雑さ、特定の命令の使用、関数呼び出しの頻度と期間を測定する動的プログラム分析の形式です。最も一般的には、プロファイリング情報はプログラムの最適化、より具体的にはパフォーマンス エンジニアリングに役立ちます。

プロファイリングは、プロファイラー(またはコード プロファイラー)と呼ばれるツールを使用して、プログラムのソース コードまたはそのバイナリ実行可能形式をインストルメント化することによって実現されます。プロファイラーは、イベント ベース、統計、インストルメント化、シミュレーションなどのさまざまな手法を使用します。

プロファイラーは、ハードウェア割り込み、コードインストルメンテーション、命令セットシミュレーション、オペレーティング システムフック、パフォーマンスカウンターなど、さまざまな手法を使用してデータを収集します。

プログラム分析ツールは、プログラムの動作を理解する上で非常に重要です。コンピュータ アーキテクトは、新しいアーキテクチャでプログラムがどの程度うまく動作するかを評価するために、このようなツールを必要とします。ソフトウェア作成者は、プログラムを分析し、コードの重要なセクションを識別するためのツールを必要とします。コンパイラ作成者は、命令スケジューリングや分岐予測アルゴリズムがどの程度うまく動作しているかを調べるために、このようなツールをよく使用します...

—  ATOM、PLDI

プロファイラーの出力は次のようになります。

• 観察されたイベントの統計的要約（プロファイル）

サマリー プロファイル情報は、イベントが発生したソース コード ステートメントに対して注釈付きで表示されることが多いため、測定データのサイズはプログラムのコード サイズに比例します。

/* ------------ ソース-------------------------- count */             
0001 X = "A" の場合 0055
0002 次に                       
0003 XCOUNT 0032に1を加算
0004 そうでなければ
0005 X = "B" の場合 0055

• 記録されたイベントのストリーム（トレース）

順次プログラムの場合、通常は概要プロファイルで十分ですが、並列プログラムのパフォーマンスの問題 (メッセージの待機や同期の問題) はイベントの時間関係に依存することが多いため、何が起こっているかを理解するには完全なトレースが必要になります。

（完全な）トレースのサイズはプログラムの命令パスの長さに比例するため、やや非実用的です。したがって、トレースはプログラムのある時点で開始され、別の時点で終了して出力を制限することができます。

• ハイパーバイザーとの継続的なやり取り（例えば、オンスクリーン表示による継続的または定期的な監視）

これにより、実行中のプログラムに関する進行中のメトリックを表示するだけでなく、実行中の任意の時点でトレースをオンまたはオフに切り替えることができます。また、重要なポイントで非同期プロセスを一時停止して、他の並列プロセスとのやり取りをより詳細に調べることもできます。

プロファイラーは、個々のメソッドに適用することも、モジュールやプログラムの規模に適用することもできます。長時間実行されるコードを明らかにすることで、パフォーマンスのボトルネックを特定できます。^{[1]プロファイラーは、さまざまな実行時条件[2]}やさまざまな負荷に対応できるように最適化することを目的として、タイミングの観点からコードを理解するために使用できます。 ^{[3]プロファイリングの結果は、}プロファイルに基づく最適化を提供するコンパイラーに取り込むことができます。^[4]プロファイリングの結果を使用して、個々のアルゴリズムの設計と最適化をガイドできます。Kraussマッチング ワイルドカード アルゴリズムはその一例です。^{[5]プロファイラーは、}分散アプリケーションのトランザクションワークロードに関する洞察を提供するためにプロファイリング データを集約する一部のアプリケーション パフォーマンス管理システムに組み込まれています。^[6]

パフォーマンス分析ツールは、1970 年代初頭からIBM/360およびIBM/370プラットフォームに存在していました。通常、タイマー割り込みに基づいており、設定されたタイマー間隔でプログラム ステータス ワード(PSW) を記録して、実行中のコードの「ホット スポット」を検出します。 ^{[引用が必要]これは、}サンプリングの初期の例です(以下を参照)。1974 年初頭には、命令セット シミュレーターによって完全なトレースとその他のパフォーマンス監視機能が許可されました。^{[引用が必要]}

Unixにおけるプロファイラ駆動型プログラム解析は1973年にまで遡ります^[7] 。当時Unixシステムには、各関数とそれがプログラム実行に要した時間をリストする基本ツールが含まれていましたprof。1982年にgprofこの概念は完全なコールグラフ解析に拡張されました^{[8] 。}

1994年、Digital Equipment CorporationのAmitabh SrivastavaとAlan Eustaceは、ATOM ^[9] (Analysis Tools with OM) について説明した論文を発表しました。ATOMプラットフォームは、プログラムを独自のプロファイラーに変換します。コンパイル時に、分析するコードをプログラムに挿入します。挿入されたコードは分析データを出力します。プログラムを変更して自分自身を分析するこの手法は、「インストルメンテーション」として知られています。

2004年には、およびATOMの論文が、1999年までの20年間で最も影響力のあるPLDIgprof論文50選のリストに掲載されました。^[10]

フラット プロファイラーは、呼び出しから平均呼び出し時間を計算し、呼び出し先またはコンテキストに基づいて呼び出し時間を細分化しません。

コールグラフプロファイラ^[8]は、関数の呼び出し時間と頻度、および呼び出し先に基づいて関連する呼び出しチェーンを表示します。一部のツールでは、完全なコンテキストが保持されません。

入力依存プロファイラー^{[11] [12] [13]}は、フラットプロファイラーやコールグラフプロファイラーに、入力サイズや入力値などの入力ワークロードの特徴にパフォーマンス指標を関連付けることにより、新たな次元を追加します。入力に応じてアプリケーションのパフォーマンスがどのように変化するかを示すグラフを生成します。

プロファイラーはプログラムそのものでもあり、実行に関する情報を収集することで対象プログラムを分析します。データの粒度、つまりプロファイラーが情報を収集する方法に基づいて、イベントベースのプロファイラーと統計プロファイラーに分類されます。プロファイラーはプログラムの実行を中断して情報を収集するため、時間測定の解像度が制限される可能性があり、これは鵜呑みにしないでください。基本ブロックプロファイラーは、各コード行の実行に費やされたマシンクロックサイクルの数、またはこれらを合計したタイミングを報告します。基本ブロックごとに報告されるタイミングは、キャッシュヒットとキャッシュミスの違いを反映しない場合があります。^{[14] [15]}

ここにリストされているプログラミング言語には、イベントベースのプロファイラーがあります。

• Java : JVMTI (JVM ツール インターフェース) API (旧称 JVMPI (JVM プロファイリング インターフェース)) は、呼び出し、クラスのロード、アンロード、スレッドの開始/終了などのイベントをトラップするためのプロファイラーへのフックを提供します。
• .NET :プロファイリングAPIを使用して、プロファイリング エージェントをCOMサーバーとしてCLRに接続できます。Java と同様に、ランタイムは、メソッドJIT /enter/leave、オブジェクト作成などのイベントをトラップするために、エージェントにさまざまなコールバックを提供します。プロファイリング エージェントがターゲット アプリケーションのバイトコードを任意の方法で書き換えることができるという点で特に強力です。
• Python : Python プロファイリングには、プロファイル モジュール、hotshot (呼び出しグラフ ベース)、および 'sys.setprofile' 関数を使用して c_{call,return,exception}、python_{call,return,exception} などのイベントをトラップすることが含まれます。
• Ruby : Ruby もプロファイリングに Python と同様のインターフェースを使用します。profile.rb の flat-profiler、モジュール、および C 拡張機能の ruby​​-prof が存在します。

一部のプロファイラーはサンプリングによって動作します。サンプリング プロファイラーは、オペレーティング システムの割り込みを使用して、対象プログラムの呼び出しスタックを定期的に調査します。サンプリング プロファイルは、通常、数値的な正確性と特定性が低くなりますが、対象プログラムをほぼフル スピードで実行できます。

得られたデータは正確ではなく、統計的な近似値です。「実際の誤差は通常、1つのサンプリング期間以上です。実際、値がサンプリング期間のn倍である場合、その値の予想される誤差はnサンプリング期間の平方根です。」^[16]

実際には、サンプリング プロファイラーは、ターゲット プログラムにそれほど干渉せず、副作用 (メモリ キャッシュや命令デコード パイプラインなど) もそれほど多くないため、他のアプローチよりもターゲット プログラムの実行をより正確に把握できることがよくあります。また、実行速度にそれほど影響しないため、通常は隠れている問題を検出できます。また、頻繁に呼び出される小さなルーチンや「タイトな」ループのコストを過大評価することもありません。システム コール処理などの割り込み可能なカーネル モードと比較して、ユーザー モードで費やされた時間の相対的な量を表示できます。

それでも、割り込みを処理するカーネル コードでは、CPU サイクルがわずかに失われ、キャッシュの使用が転用され、割り込み不可能なカーネル コードで発生するさまざまなタスク (マイクロ秒単位のアクティビティ) を区別することができません。

専用ハードウェアはこれを超えることができます。ARM Cortex-M3 および一部の最近の MIPS プロセッサの JTAG インターフェイスには PCSAMPLE レジスタがあり、プログラム カウンターを完全に検出できない方法でサンプリングして、フラット プロファイルの非侵入的な収集を可能にします。

Java/マネージドコード用の一般的に使用されている^{[17]統計プロファイラとしては、} SmartBear SoftwareのAQtime ^[18]やMicrosoftのCLR Profiler ^[19]などがあります。これらのプロファイラはネイティブコードのプロファイリングもサポートしており、Apple Inc.のShark (OSX) ^{[20] 、} OProfile (Linux) ^{[21] 、} Intel VTuneおよびParallel Amplifier ( Intel Parallel Studioの一部)、Oracle Performance Analyzer ^[22]などもサポートしています。

この手法は、必要な情報を収集するために、ターゲット プログラムに命令を効果的に追加します。プログラムをインストルメントするとパフォーマンスが変化する可能性があり、場合によっては不正確な結果やハイゼンバグが発生する可能性があります。効果は、収集される情報、報告されるタイミングの詳細のレベル、および基本ブロック プロファイリングがインストルメントと組み合わせて使用​​されるかどうかによって異なります。^[23] たとえば、すべてのプロシージャ/ルーチン呼び出しをカウントするコードを追加しても、各ステートメントの実行回数をカウントするよりも効果は低くなります。少数のコンピューターには、情報を収集するための特別なハードウェアが搭載されています。この場合、プログラムへの影響は最小限です。

計測は、プロファイラーで利用できる制御レベルと時間分解能を決定する上で重要です。

• 手動: プログラマーによって実行されます。たとえば、実行時間を明示的に計算する命令を追加したり、イベントをカウントしたり、アプリケーション応答測定標準などの測定APIへの呼び出しをカウントしたりします。
• 自動ソース レベル: インストルメンテーション ポリシーに従って自動ツールによってソース コードに追加されるインストルメンテーション。
• 中間言語:アセンブリまたは逆コンパイルされたバイトコードにインストルメンテーションが追加され、複数の高レベルソース言語がサポートされ、(非シンボリック) バイナリ オフセットの書き換えの問題が回避されます。
• コンパイラ支援
• バイナリ変換: ツールはコンパイルされた実行可能ファイルにインストルメンテーションを追加します。
• ランタイム インストルメンテーション: 実行直前にコードがインストルメントされます。プログラムの実行はツールによって完全に監視および制御されます。
• ランタイム インジェクション: ランタイム インストルメンテーションよりも軽量です。コードは実行時に変更され、ヘルパー関数にジャンプします。

• インタープリタのデバッグオプションを使用すると、インタープリタが各ターゲット ステートメントに遭遇したときにパフォーマンス メトリックを収集できます。バイトコード、制御テーブル、またはJITインタープリタは、通常、ターゲット コードの実行を完全に制御し、非常に包括的なデータ収集の機会を可能にする 3 つの例です。

• ハイパーバイザー: データは、ハイパーバイザーの下で (通常は) 変更されていないプログラムを実行することによって収集されます。例: SIMMON
• シミュレーターとハイパーバイザー:命令セットシミュレーターで変更されていないプログラムを実行することにより、対話型かつ選択的に収集されたデータ。

• IBM Rational Application Developer を使用して Java アプリケーションの実行時間分析を行う方法に関する記事「スピードの必要性 - パフォーマンスのボトルネックの解消」。
• VTune パフォーマンス アナライザーを使用したランタイム生成および解釈されたコードのプロファイリング