JP2008537222A - ソフトウェアプログラムに関するパフォーマンス分析の方法と装置 - Google Patents

Abstract

ソフトウェアに関するパフォーマンステスト情報を表示するシステムが開示されている。本システムは、パフォーマンス上の問題とその原因の即時特定を可能にするフォーマットで情報を表示するグラフィカルユーザインタフェースを具備している。このインタフェースは、テスト対象プログラムの実行期間にアクティビティレベルを示す時系列ビュー（ｔｉｍｅｌｉｎｅ ｖｉｅｗ）を含んでいる。プログラム実行期間における時間のサブレンジ期間のイベントは、そのプログラムを構成するスレッドのやりとり（ｉｎｔｅｒａｃｔｉｏｎｓ）を示す情報と共に表示可能になっている。追加情報は、テキスト情報と共に、別の表示フィールドに表示可能になっている。表示される情報の多くはグラフィカルに表現されているので、パフォーマンスエンジニアはさらに調査すべきプログラムの個所を迅速に特定できるようにしている。

Description

本発明は、一般的にはソフトウェアプログラム開発に関し、具体的にはソフトウェアプログラムのパフォーマンス分析に関する。

ソフトウェアプログラムは、その開発期間にテストされるのが一般的である。従来から、このテストは、ソフトウェアプログラムが関数を意図通りに実行することを検証するために使用されている。ソフトウェアプログラムが複雑化するのに伴い、パフォーマンステストは、開発サイクルの重要なコンポーネントになっている。パフォーマンステストは、「パフォーマンスエンジニアリング」作業をサポートし、その作業期間にプログラム実行の遅延の原因となったプログラム部分が特定され、プログラム実行に要する時間を短縮するように書き直されている。

パフォーマンステストは、テスト対象プログラムの中に「プローブ（ｐｒｏｂｅ）」を挿入することによって行なわれることが多い。プローブは、その実行時にログファイルにデータを書き込む単純な関数である。ログファイル内のデータはそのあと分析され、プログラム動作の種々の特性を判断することを可能にしている。

従来のパフォーマンス分析ツールは、ログファイル内のデータを使用してテスト対象ソフトウェアプログラムの実行の集約ビュー（ａｇｇｒｅｇａｔｅｄ ｖｉｅｗ）を提示している。例えば、ログファイル内のデータは、テスト対象ソフトウェアプログラムの中の各関数が起動される回数を判断するために使用されることがある。この情報から、パフォーマンスエンジニアは、例えば、特定の関数が意図する回数以上に実行されるループに入っていることを知ることができる。そのような観察により、例えば、ループが実行される回数を減らすようにプログラムを作り直すと、プログラムのパフォーマンスを向上させることができる。

データの集約ビューからは、各関数が実行される平均時間量を知ることもできる。ある関数の平均実行時間が期待実行時間を大幅に超えていれば、パフォーマンスエンジニアは、なんらかのイベントがその関数の実行をブロック（ｂｌｏｃｋ）しているかどうかを調べることができる。

パフォーマンスエンジニアがレビューするために、テスト対象ソフトウェアプログラムに関するパフォーマンスデータを提示するツールが、採用されている。この種のルールは、例えば、パフォーマンスエンジニアが複数のタイプの集約データから選択することを可能にして、パフォーマンスエンジニアがテスト対象ソフトウェアプログラムのさまざまな側面を検査できるようにしている。また、この種のツールには時系列ビュー（ｔｉｍｅｌｉｎｅ ｖｉｅｗｓ）も含まれているので、パフォーマンスエンジニアは、テスト対象ソフトウェアプログラムのアクティビティレベルを見ることができる。

本発明は、テスト対象ソフトウェアプログラムに関するパフォーマンスデータを提供するユーザインタフェースに関する。このユーザインタフェースを使用すると、パフォーマンスエンジニアまたは他のユーザは、テスト対象ソフトウェアプログラムのうち、パフォーマンス上の問題の原因となっている可能性のある部分をより即時に特定できるようにパフォーマンスデータの提示を操作することができる。

本発明の一側面では、テスト対象ソフトウェアプログラムに関するパフォーマンスデータを表示する方法が提供されている。この方法によれば、テスト対象ソフトウェアプログラムが実行される期間のタイムレンジ（ｔｉｍｅ ｒａｎｇｅ）の表現が第１ディスプレイエリアに表示される。第１ディスプレイエリアに表示されたタイムレンジの指示部分（ｉｎｄｉｃａｔｅｄ ｐｏｒｔｉｏｎ）を示すユーザインプットはユーザインタフェースデバイスを通して受信される。複数のグラフィカルインジケータ（ｇｒａｐｈｉｃａｌ ｉｎｄｉｃａｔｏｒ）は、第２ディスプレイエリアに表示される。各グラフィカルインジケータは、タイムレンジのサブレンジ（ｓｕｂ−ｒａｎｇｅ）期間における複数のスレッドの１つの実行でのイベントを表わしている。サブレンジには、第１ディスプレイエリアに表わされたタイムレンジの指示部分が含まれている。

本発明の別の側面では、テスト対象ソフトウェアプログラムの中の複数のスレッドに関するパフォーマンスの情報がそこにレンダリングされているディスプレイデバイスが、提供されている。パフォーマンスの情報は、複数のスレッドの各々について、スレッドの動作を表わすスレッドエリアを含んでいる。スレッドエリアには少なくとも１つのインジケータがあり、各々のインジケータはスレッドの動作イベント（ｏｐｅｒａｔｉｎｇ ｅｖｅｎｔ）を表わし、複数のスレッドのスレッドエリアは、複数のスレッドのスレッドエリア内のインジケータが複数のスレッドにおける動作イベントの時間的相関関係をグラフィカルに示すような位置に置かれている。

さらに、本発明の別の側面では、テスト対象ソフトウェアプログラムのパフォーマンスを分析するためのコンピュータ実行可能コンポーネントを収めたコンピュータ可読媒体が提供されており、テスト対象ソフトウェアプログラムは、複数のスレッドで実行されるように構成されている。コンピュータ実行可能コンポーネントは、テスト対象ソフトウェアプログラムの中の複数のスレッドの実行に関するデータを収集するように構成されたデータ収集コンポーネント（ｄａｔａ ｃｏｌｌｅｃｔｉｏｎ ｃｏｍｐｏｎｅｎｔ）、収集されたデータを分析して複数のスレッドに関する実行データを導き出すように構成された分析コンポーネント（ａｎａｌｙｓｉｓ ｃｏｍｐｏｎｅｎｔ）、および複数のスレッドの少なくとも一部分に関する実行情報を、人間が目に見える形式で表示するように構成された報告コンポーネント（ｒｅｐｏｒｔｉｎｇ ｃｏｍｐｏｎｅｎｔ）を含み、人間が目に見える形式は、前記一部分の中の複数のスレッドの各々について時間の関数として実行情報をグラフィカルに表現したものを含み、一部分の中の複数のスレッドの各々のグラフィカル表現は、一部分の中の複数のスレッドの各々におけるイベントを、時間的に相関付けることを可能にするフォーマットで表示されるようにしている。

添付図面は、一律の縮尺で描かれることを目的としていない。図面において、各図面に示されている各々の同一またはほぼ同一のコンポーネントは類似の符号で示されている。明確化のために、すべてのコンポーネントがすべての図面において標識付けされているとは限らない。

パフォーマンスの分析のために使用できる改良パフォーマンス分析ツールが提供されている。このツールは、パフォーマンス分析情報を複数のフォーマットで提示するので、データを異なるフォーマットで提示するディスプレイエリアを構成することを可能にしている。構成可能であるため、パフォーマンスエンジニアなどのユーザは、テスト対象プログラムの中でパフォーマンス上の問題が発生した個所を特定できると共に、パフォーマンス上の問題の原因まで「掘り下げて（ｄｒｉｌｌ ｄｏｗｎ）」その原因を突き止めることができる。

図１は、この種のツールが使用できる開発環境１００を示すブロック図である。開発環境１００は、例えば、コンピュータワークステーションやサーバで構築することも、ネットワークで結ばれたコンピュータのグループやプログラムを実行できる他の適当なプラットフォーム上で構築することもできる。

テスト対象プログラム（ｐｒｏｇｒａｍ ｕｎｄｅｒ ｔｅｓｔ）１１０は、ここでは複数のプロセスから構成されているものとして示されている。図１の例では、プロセス１１２₁、１１２₂および１１２₃が示されている。テスト対象プログラム１１０の中のプロセスの数は本発明を限定するものではない。なお、本発明は、多数のプロセスを含むテスト対象プログラムのパフォーマンスを分析するのに利用すると、非常に便利である。

各プロセスは、「スレッド」を実行することができる。スレッド（ｔｈｒｅａｄ）とは、大部分のケースでは、プロセスの中で実行されるプログラムの一部である。従って、プロセスとスレッドは密接に関係のある概念である。各スレッドは関数コール（ｆｕｎｃｔｉｏｎ ｃａｌｌ）と他のプログラムイベント（ｐｒｏｇｒａｍ ｅｖｅｎｔ）のシーケンスを独自に持っている。

別個のプロセス群を別個のプロセッサ群上で実行させることができる。しかし、別個のプロセス群を、シングルプロセッサ上で作成することができる。プロセッサのリソースは、プロセス間で共有され、任意の時点でアクティブ状態にあるすべてのスレッドは順番にプロセッササイクルを消費している。１つのプロセスがある時点でプロセッササイクルを消費している場合であっても、複数のスレッドはシングルプロセッサ上で「仮想的に」アクティブでいることができる。

上記とは対照的に、スレッドは利用可能なプロセッサの数に関係なく、「ブロック（ｂｌｏｃｋ）」されることがある。マルチプロセスシステムには、別々のプロセスで実行されるスレッド間でデータをやりとりするメカニズムが用意されている。あるスレッドが別のスレッドとデータをやりとりする必要が起こった場合、これらの２スレッドは同時にデータをやりとりできる状態にないことがある。従って、他方のスレッドがデータをやりとりするために読み取られる個所まで実行されるまで、一方のスレッドを待たせる必要が起こる場合がある。別のスレッドがデータをやりとりするまで、あるいは他の何らかの関数を実行するまであるスレッドが待っている間、そのスレッドは「ブロック」されていると言う。重要なイベントでスレッドを「ブロック」すると、プログラムのパフォーマンスに影響を与えることになる。

図１に図示の例では、プロセス１１２₁、１１２₂および１１２₃の各々は、従来技術に見られるような、プローブ関数（ｐｒｏｂｅ ｆｕｎｃｔｉｏｎ）を備えている。テスト対象プログラム１１０が実行されると、このプローブ関数は、データをデータファイル１２０に書き込む。この実施形態で、データファイル１２０は、複数バッファ１２２₁、１２２₂ ．．．１２２₅として編成されている。この実施形態では、テスト対象プログラム１１０の中のプロセスの各々に１つのバッファが用意されている。

テスト対象プログラム１１０が実行されると、プロセス１１２₁、１１２₂および１１２₃内に埋め込まれたプローブが実行される。別々のプロセスの中のプローブは、そのプロセスに関連するバッファにデータ値を書き込む。このようにして、バッファ１２２₁、１２２₂ 、および１２２₃の各々には、その実行時にそのプロセス内で発生したイベントの順序付けリスト（ｏｒｄｅｒｅｄ ｌｉｓｔ ｏｆ ｅｖｅｎｔｓ）が収められている。スレッドとプロセスは密接な関係があるため、この情報を利用すると、イベントが関係するスレッドを特定することもできる。図示の実施形態では、バッファに書き込まれる各イベントには、そのイベントを示すインジケータがそのイベントが発生した時刻と共に含まれている。

図示の実施形態で、テスト対象プログラム１１０は、予め定められたアプリケーションプログラミングインタフェース（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ（ＡＰＩ））を通してコールが行なわれると、イベントがバッファに記録されるように作られている。図示の例で、予め定められたＡＰＩを通したコールは、バッファ１２２₄に記録される。バッファ１２２₄は、ＡＰＩのどの部分がコールされたのか、どのプロセスからそのコールが行なわれたのか、およびそのコールがいつ行なわれたのか、を特定する情報をストアしている。

テスト対象プログラム１１０は、オペレーティングシステム１１４を含んでいるプロットフォーム上で実行されている。この実施形態で、オペレーティングシステム１１４は、種々のイベントをデータファイル１２０に書き込むようにも構成されている。例外条件（ｅｘｃｅｐｔｉｏｎ ｃｏｎｄｉｔｉｏｎ）やディスクアクセス（ｄｉｓｋ ａｃｃｅｓｓ）のような、予め定められたイベントはイベントの通知をデータファイル１２０に書き込むようにオペレーティングシステム１１４の内部にプログラミングすることもできる。このようなイベントが発生すると、その通知は、バッファ１２２₅に書き込まれる。イベントの通知には、発生した特定イベントのＩＤ、そのイベントが発生した時刻およびそのイベントを発生させる原因となったスレッドのプロセスを含めることができる。

図１は、テスト対象ソフトウェアプログラムの実行期間にキャプチャ（ｃａｐｔｕｒｅ）することができるイベントのタイプを例示している。本発明の一実施形態によれば、多くのタイプのイベントは、人間のユーザ（ｈｕｍａｎ ｕｓｅｒ）に使い易い形式で表示されるようになっている。例えば、ＳＱＬイベント、ＯＳカーネルイベント、ウェブサーバイベントまたは他の所望のタイプのイベントを、以後の分析と表示のためにデータファイル１２０にキャプチャしておくことができる。

図示の実施形態で、データファイル１２０にストアされたデータは、プログラム１１０の実行後に分析される。この分析は分析プログラム（ａｎａｌｙｓｉｓ ｐｒｏｇｒａｍ）１３０によって行なわれる。ここで説明している実施形態で、分析プログラム１３０は、バッファ１２２₁．．．１２２₅の各々にストアされたイベントの時間を相関付ける。バッファの各々の中のイベントの時刻を相関づけるにはさまざまな方法を利用できる。ここで説明している実施形態では、インデックスが作成される。インデックスは、各バッファ内のどのエントリがテスト対象プログラム１１０の実行期間の特定時刻に対応しているかを示している。このようにすると、分析されたデータが処理されるとき、分析プログラム１３０は、テスト対象プログラム１１０の実行期間の特定時点に対応するデータを、バッファの各々から即時にアクセスすることができる。インデックスは、特定時刻に発生しているイベントに対応する、各バッファ内のロケーションの推定値をインデックスが表わすように適応的に作成することができる。データファイル１２０が処理されるとき、これらの推定値は更新されることがある。しかし、インデックスを作る方法が適切であれば、どのような方法でも使用できる。

データファイル１２０にストアされたデータにインデックスを付けると、分析プログラム１３０は、異なるプロセス内のイベントが共通時間フレーム（ｃｏｍｍｏｎ ｔｉｍｅ ｆｒａｍｅ）を基準にして表示されるように、即時にデータをユーザインタフェース１４０から表示するフォーマットにすることができる。異なるプロセスまたはスレッドでのイベントを相関付けるとき、絶対標準を基準にして時刻をトラッキングする必要がない。むしろ、テスト対象プログラム１１０の実行開始または他の好都合な個所を基準にして時刻をトラッキングすることができる。時刻は、例えば、テスト対象プログラム１１０がそこで実行されているプロセッサ内部のクロックの刻み（ｔｉｃｋ）を基準にしてトラッキングすることができる。

図示の実施形態で、ユーザインタフェース１４０は、コンピュータワークステーションの一部になっている。しかし、適切であれば、どのようなユーザインタフェースデバイスでも採用できる。この例で、ユーザインタフェース１４０は、アウトプットメカニズムを備えたディスプレイ１４２を含んでいる。ディスプレイ１４２は、例えば、アウトプットを人間のユーザに提供することを可能にするＣＲＴまたはＴＦＴディスプレイにすることができる。他の形体のアウトプットデバイスを使用することもできる。例えば、グラフィカルアウトプットは印刷することも、スクリーン上に投影させることもできる。別の方法として、アウトプットを他のプログラムまたはシステムに渡し、使用に先立って詳細分析を行なってから情報をユーザに提供することもできる。

ユーザインタフェース１４０は、ユーザインタフェース選択デバイスを含んでいる。このユーザインタフェース選択デバイスを使用すると、ユーザは分析プログラム１３０の動作を制御できるインプットを、ユーザインタフェース１４０から与えることができる。図示の実施形態で、ユーザインタフェース１４０は、ユーザのインプットをユーザインタフェース１４０から与えるために使用できるマウス１４６を含んでいる。従来のデスクトップコンピュータの場合と同様に、人間のユーザは、マウスを操作してカーソルをディスプレイ１４２上に位置づけ、マウス１４６のボタンを操作して（つまり、「クリック」して）ディスプレイ１４２上のインプットアイテムとして選択することができる。ユーザインタフェース１４０からは、ボタンが押されたときの位置に基づいてプログラムオブジェクトを起動させることができる。

キーボード１４４は単独でも、マウス１４６との併用でも、ユーザインタフェース選択デバイスとして働かせることもできる。人間のユーザは、キーボード１４４を使用して、インプットをユーザインタフェース１４０から与えるのに適したコマンド、パラメータまたは他の情報を入力することができる。ここで説明している実施形態で、ユーザのインプットは、望ましい表示をディスプレイ１４２から得られるように分析プログラム１３０を制御している。

図２は、分析プログラム１３０によって作成され、テスト対象ソフトウェアプログラムの実行期間に収集されたデータを、人間のユーザに提示するためにディスプレイ１４２から表示できるサンプルユーザインタフェース２１０を示す図である。図２の実施形態で、ユーザインタフェース２１０は、複数の領域を収めている。ここで説明している実施形態で、これらの領域は、論理的に関係のある情報をグループ化するために使用される。例えば、メニューバー２１２は、ユーザインタフェース２１０の情報または機能を制御するためにユーザがアクセスできるコマンドを見つけるための領域の働きをする。メニューバー２１０に含まれるコマンドは、特定のファイルをオープンまたはクローズするコマンドのように、従来のグラフィカルユーザインタフェースで使用されているコマンドにすることができる。コマンドは、ユーザインタフェース２１０の残り部分に表示される情報を表示することも、テスト対象ソフトウェアプログラムの実行から収集されたパフォーマンスデータを表示するために使用されるユーザインタフェースに固有の操作を制御することもできる。

図２に図示の実施形態で、ユーザインタフェース２１０は、３つの領域を収めており、テスト対象ソフトウェアプログラム１１０の実行に関する情報であって、論理的に関係があるが、異なるタイプの情報がそこに表示される。これらの領域は時系列（ｔｉｍｅｌｉｎｅ）フィールド２２０、スレッドビュー（ｔｈｒｅａｄｖｉｅｗ）フィールド２３０およびテキストビュー（ｔｅｘｔｖｉｅｗ）フィールド２６０を含んでいる。

時系列フィールド２２０は、テスト対象ソフトウェアプログラム１１０の実行期間のアクティビティのレベルをグラフィカルに表現したものを含んでいる。この実施形態で、アクティビティのレベルは、時系列フィールド２２０内に陰影付け（ｓｈａｄｉｎｇ）することで示される。例えば、領域２２２は領域２２４よりも陰影付けが少なくなっている。この陰影付けは、領域２２４に比べて領域２２２で表わされた時間期間に少ないアクティビティが行なわれたこと、すなわち、領域２２２で表わされた時間期間のアクティビティが少ないことを示している。

この例で、テスト対象ソフトウェアプログラム１１０の実行全体は、左から右に向かう時系列で表わされている。適切であれば、どのようなアクティビティの表現形体でも使用できる。例えば、異なるアクティビティレベルを示すために異なるカラーを使用することができる。別の方法として、時系列フィールド２２０で表わされた時系列をヒストグラム（ｈｉｓｔｏｇｒａｍ）として表示し、時系列のディスプレイの高さがテスト対象ソフトウェアプログラム１１０の実行期間の任意の特定時刻におけるアクティビティレベルを示すようにすることができる。

アクティビティのレベルは適切であれば、どのような方法でも測定することができる。実行中のプログラムによって消費されるＣＰＵ時間の割合（パーセンテージ）をトラッキングするプロセスモニタはこの分野では公知であり、これは、例えば、２２０のように、アクティビティのレベルを示す時系列フィールドを生成するデータを作成するために使用することができる。この実施形態で、時系列フィールド２２０は、テスト対象ソフトウェアプログラム１１０の部分を実行するプロセス１１２₁、１１２₂および１１２₃のすべての集約アクティビティ（ａｇｇｒｅｇａｔｅ ａｃｔｉｖｉｔｙ）を示している。この例で、時系列フィールドには、オペレーティングシステム１１４の一部であるプログラムを実行するプロセスにおけるアクティビティに関する情報は含まれていない。

時系列フィールド２２０は、タイムインジケータ（ｔｉｍｅ ｉｎｄｉｃａｔｏｒ）２２６を含んでいる。タイムインジケータ２２６は、ユーザが操作できるコントロールである。例えば、タイムインジケータ２２６は、ユーザがマウス１４６（図１）を操作することで選択できる。そのあと、ユーザはマウス１４６を操作すると、プログラムインタフェースで常用されているドラッグアンドドロップアクションを使用してタイムインジケータ２２６を時系列フィールド２２０上の関心のある望みの個所にスライドすることができる。このようにすると、ユーザは、データファイル１２０（図１）にストアされたデータ部分を指定して、さらに詳しく調べることができる。具体的には、タイムインジケータ２２６によって指定された実行時間のサブレンジの間に収集されたデータは、スレッドビューフィールド２３０にさらに詳しく表示させることができる。

図示のように、タイムインジケータ２２６は、単一の時間を指定している。スレッドビューフィールド２３０に表示させる時間の範囲をユーザが指定するには、さまざまな実施形態が可能である。この例で、スレッドビューフィールド２３０には、テスト対象ソフトウェアプログラム１１０の動作に関する情報がタイムインジケータ２２６によって示された時間の前後の時間サブレンジで収められている。しかし、適切であれば、どのような規則でも使用可能である。例えば、時系列フィールド２２０には、あるタイムインジケータは、スレッドビューフィールド２３０に表示させるインターバルの開始を特定し、別のタイムインジケータは、スレッドビューフィールド２３０に表示させる終了時間を特定する、といったように複数のインジケータを含めることができる。

スレッドビューフィールド２３０に表示する時間のサブレンジを特定するためにどのようなメカニズムが使用されるかに関係なく、スレッドビューフィールド２３０は、選択されたインターバル期間にテスト対象ソフトウェアプログラム１１０の一部として実行されるスレッド内のイベントをグラフィカルに表現したものを収めている。図２に示す実施形態で、各スレッドはエリアで表わされ、ここではトレースバー（ｔｒａｃｅ ｂａｒ）
２４０₁、２４０₂．．．２４０₉として示されている。ここでは、９個のスレッドが示されている。イベントが示されるときのスレッドの数は、本発明を限定するものではない。

各スレッド内のイベントは、対応するトレースバー内にグラフィカルに示されている。複数のタイプのイベントが示されている。イベントの数とタイプは単なる例示であり、表示できるイベントの数またはタイプは任意である。

図２に示す実施形態で、トレースバー２４０₁、２４０₂．．．２４０₉の各々は、その対応するスレッドが存在している時間を示している。テスト対象プログラムが動作しているとき、スレッドの開始時間と終了時間はさまざまであり、これらは、スレッドビューフィールド２３０にグラフィカルに表わされることができる。

さらに、スレッドが存在していても、アクティブでいられるのは、それが存在する時間の一部だけである。適切であれば、スレッドアクティビティはどのような尺度で測ることも可能である。しかし、図示の実施形態で、プロセッサの数が限られているシステムでは複数のプロセスがスケジューリングされるために、あるスレッドがＣＰＵサイクルをアクティブに消費していない場合でも、実行すべきオペレーションがあるとき、そのスレッドは、「アクティブ」とみなされている。ユーザインタフェース２１０で、トレースバー２４０₁、２４０₂．．．２４０₉は、対応するスレッドがアクティブであるか、あるいはブロックされている時間期間をビジュアルに示すように作られている。アクティブまたはブロックされている期間を特定するには、適切であればどのような方法を使用することもできる。この例で、アクティブインジケータ（ａｃｔｉｖｅ ｉｎｄｉｃａｔｏｒ）２４２のようなアクティブインジケータは、対応するスレッドがアクティブである期間の時間を示すためにトレースバーの上に重ねられている。これとは逆に、ブロックされたインターバル２５４におけるように、アクティブインジケータがないことは、対応するスレッドが特定のインターバル期間ブロックされていることを示している。

スレッドビューフィールド２３０には、他のイベントをグラフィカルに表示させることもできる。この例では、２４４のようなユーザマーク（ｕｓｅｒ ｍａｒｋ）が示されている。図１に関連して上述したように、テスト対象ソフトウェアプログラム１１０内のイベントを記録できる。この例で、ユーザマーク２４４の各々は、テスト対象ソフトウェアプログラム１１０のＡＰＩ内の関数へのコールが出されたことをグラフィカルに示している。システムマーク（ｓｙｓｔｅｍ ｍａｒｋ）２５０も、同じように、オペレーティングシステム１１４によってトラッキングされたイベントの１つが発生したことを示している。この例で、システムマーク２５０は、ユーザマーク２４４とビジュアルに区別可能になっている。異なるタイプのマーク間を区別するために、カラー、形状または位置付けを使用することができる。図２には、複数のユーザマークが示されている。これらのユーザマークはすべて同じグラフィカルシンボルで示されているが、これは同じイベントが複数回発生したことを表わしている。異なるタイプのユーザマークは同じまたは異なるグラフィカルシンボルで表わすことができる。

スレッドビューフィールド２３０は、タイムスケール（ｔｉｍｅ ｓｃａｌｅ）２３２を含んでいる。各トレースバー２４０₁、２４０₂．．．２４０₉内のイベントは、このタイムスケール２３２と相関付けされている。従って、トレースバー内のイベントは相互に相関付けされている。スレッドビューフィールド２３０を横に読んでいくと、スレッド内で一度に発生したイベントを比較することができる。スレッドフィールド２３０を下に読んでいくと、イベントのシーケンスが明らかになる。

タイムスケール２３２は、時系列フィールド２２０に示された時間のサブレンジを表示する。表示される特定のサブレンジは、ユーザがタイムインジケータ２２６を操作することによって選択することができる。さらに、スレッドビューフィールド２３０は、スクロールバー２５２を含んでいる。スクロールバーは、表示すべき時間サブレンジを選択するために他のメカニズムを提供する。スクロールバー２５２は、現時点で公知タイプのコントロールにすることも、グラフィカルユーザインタフェースで使用するために将来開発されるタイプのコントロールにすることもできる。スクロールバー２５２を使用すると、ユーザはスレッドビューフィールド２３０に表示されている時間サブレンジを以前または以後の時間に変換することができる。この実施形態では、タイムインジケータ２２６とスクロールバー２５２は相互に関係付けられたコントロールであり、このことは、タイムインジケータ２２６とスクロールバー２５２のどちらかを調整すると、スレッドビューフィールド２３０に表示されている時間のサブレンジのセンタポイントが調整されることを意味している。

スレッド内のイベントを相互に関係付けて表示できるので、人間のユーザは、テスト対象プログラム１１０の実行時にパフォーマンス上の問題の原因となった可能性のあるプログラム部分を即時に特定することができる。例えば、図２は、スレッド３が比較的短時間の期間アクティブであり、そのあと非アクティブになったことを示している。この非アクティブの期間に、スレッド４は、比較的長時間の期間アクティブになっている。そのあと、スレッド４は、非アクティブになり、スレッド３は、再びアクティブになっている。このようなパターンから、例えば、人間のユーザは、スレッド４で待たされている間スレッド３がブロックされていることを知ることができる。また、このパターンから、スレッド４の実行に必要な時間を調べるか、あるいはスレッド３がスレッド４を待っている間本当にブロックされていたかどうかを調べることにより、プログラム全体のパフォーマンスを改善できることを知ることができる。このようなシナリオは、集約統計（ａｇｇｒｅｇａｔｅｄ ｓｔａｔｉｓｔｉｃｓ）を見るだけでは明らかにならない。集約統計からは、スレッド３の実行時間が長かったことを知ることができるが、その原因を知ることはできない。

図２は、ユーザインタフェース２１０に含まれるテキストビュー（ｔｅｘｔ ｖｉｅｗ）フィールド２６０を使用すると、種々のスレッドの実行に関する追加データを取得できることを示している。図示の実施形態で、スレッド３とスレッド４は、テキストビューフィールド２６０に強調表示（ｈｉｇｈｌｉｇｈｔ）されている。ここで説明している実施形態で、ユーザは、どのフィールドをテキストフィールド２６０に表示させるかを選択しているが、適切であれば、テキストビューフィールド２６０に表示させるスレッドは、どのような方法を用いても選択することができる。例えば、ユーザは、スレッドビューフィールド２２０に表示されているスレッドの１つについてマウス１４６のボタンを使用してプロパティメニュー（ｐｒｏｐｅｒｔｉｅｓ ｍｅｎｕ）にアクセスし、スレッドをテキストビューフィールド２６０に表示させることを、そのメニューの中で選択することができる。別の例として、ユーザは、マウス１４６を使用して、テキストビューフィールド２６０内の望みのフィールドを表わしているトレースバーをドラッグアンドドロップすることもできる。

テキストビューフィールド２６０に表示するために選択された各スレッドは、２６４₁または２６４₂のようなイベントトレース（ｅｖｅｎｔ ｔｒａｃｅ）によって表わされている。各イベントトレースには、イベントトレースによって示されたスレッド内のイベントをリストしたものが含まれている。この例で、イベントトレース２６４₁または２６４₂にリストされたイベントは、スレッドによって起動された特定のＡＰＩへのコールやオペレーティングシステムのユーティリティのアクセスのように、スレッドから行なわれた関数へのコールおよびマークイベントを表わしている。しかし、どのような望みタイプのイベントを表示させることもできる。例えば、ＳＱＬイベント、ＯＳカーネルイベント、ウェブサーバイベントなどを、図２に示すイベントに代えて表示させることも、付加的に表示させることもできる。

テキストビューフィールド２６０は、タイムスケール２６２を含んでいる。タイムスケール２６２は、テキストビューフィールド２６０に示されたイベントトレースが、テスト対象ソフトウェアプログラム１１０が実行されている時間のサブレンジ内のイベントを説明していることを示している。テキストビューフィールド２６０に示された時間のサブレンジは、スレッドビューフィールド２３０に示されたサブレンジと同じにすることができる。しかし、図２の例で、テキストビューフィールド２６０は、テキストビューフィールド２６０に示されたサブレンジのセンタポイントを調整するためにユーザインプットによって操作できるスクロールバー２６４を含んでいる。

タイムスケール２６２は、ここでは不連続であると示されている。図示実施形態では、エントリがテキストビューフィールド２６０に作られるのは、表示のためのイベントがそのときにあるときだけである。このようにすると、連続するイベントは、これらイベントの発生時刻の間に時間的ギャップがあっても、相互に隣接して表示されることになる。

図２の例で、スレッドビューフィールド２３０とテキストビューフィールド２６０は、同時に表示されるが、異なるサイズになっている。この実施形態で、これらのフィールドは、従来のユーザインタフェースで使用されているようなディスプレイエリアとして実現されているので、各ウィンドウに表示されるデータ量を増減するために、適切ならばどのような方法でもサイズを変えることができる。また、図示実施形態で、時系列フィールド２２０、テキストビューフィールド２６０およびトレースビューフィールド２３０は、ディスプレイ上に同時に表示されている。各フィールドを別々の時刻に表示させることも、望みの組み合わせで同時に表示させることもできる。

テキストビューフィールド２６０は、テスト対象ソフトウェアプログラム１１０のパフォーマンスの分析を容易化することができる。図示の例で、スレッド３のイベントトレース２６４₁は、時刻６にスレッド３が別のスレッドを待っていることを確かめている。テキストビューフィールド２６０のさらに詳細な表示は、時刻５に実行されたＷＲＩＴＥデータ関数に続いてスレッド３が待ちに置かれていることを示している。イベントトレース２６４₂は、スレッド４がデータ書き込みに関連する種々の操作を実行中であることを示している。イベントトレース２６４₂は、スレッド４は時刻１０から始まって、＿ＳＴＲＬＥＮ関数を実行するのに相当の時間を消費していることを示している。この情報を使用すると、人間のユーザは、テスト対象プログラム１１０のパフォーマンス上の問題を即時に特定することができる。

プログラム実行のスレッドビューとイベントトレースの両方を表示すると、パフォーマンスエンジニアは、問題の原因を即時に特定することができる。グラフィカル表現を使用すると、さらに調査すべき特定個所を特定することができ、これらの特定個所の表現をテキストの形式で得ることができる。さらに、これらのフィールドの各々に表示される時刻の値のサブレンジを変更できるので、パフォーマンスエンジニアが問題を特定するときの容易さがさらに促進されることになる。例えば、スレッド３と４は時刻２３に同じようなパターンを示しているが、このことは、時刻２３に、スレッド３もスレッド４によって実行された関数へのコールを行なう可能性があることを示している。しかし、時刻２３に示す事例で、スレッド４は、時刻５に示す事例よりもはるかに短い時間の間アクティブになっている。このようなパフォーマンスデータのパターンは、スレッド３がＷＲＩＴＥデータ関数をコールするとき、そのオペレーションが他の時間よりもかなり長くなること示す場合がある。このようなパフォーマンスパターンは、どの関数が特定のパフォーマンス上の問題の原因であるかを、集約データから特定することを困難にしている。しかし、選択可能なサブレンジにわたって時間的に相関付けられた異なるスレッドにおけるイベントをユーザが調べられるようにすると、パフォーマンス上の問題の特定はさらに容易化される。

図３は、ユーザインタフェース２１０の別の特徴を示す図である。図３に示す例で、スレッドビューフィールド２３０のタイムスケール２３２は、拡張されている。この図例で、スレッドビューフィールド２３０が表示されるウィンドウは、図２のそれと同じサイズになっているが、タイムスケール２３２がカバーしているサブレンジは図２に関連して図示したもののほぼ１０分の１になっている。その結果、スレッドビューフィールド２３０に表示されたスレッド内のイベントは、より高解像度で表示される。タイムスケールの解像度を、例えば、ユーザのインプットに基づいて調整することができる。ユーザは、例えば、マウス１４６（図１）を使用してカーソルをタイムスケール２３２上に置き、そのフィールドで右クリックすると、プロパティダイアログボックス（ｐｒｏｐｅｒｔｉｅｓ ｄｉａｌｏｇ ｂｏｘ）または他のコントロールがオープンされるので、ユーザは、タイムスケール２３２の望みの解像度を指定した情報をインプットすることができる。なお、インプットを与える方法が適切なものであれば、どのような方法を用いてもタイムスケールを指定することができる。

図３は、テキストビューフィールド２６０に関連するタイムスケール２６２も、解像度がプログラム可能であることを示している。図３の例で、タイムスケール２６２の解像度は、タイムスケール２３２の解像度に一致している。なお、タイムスケール２６２の解像度は、任意の適当な手段を用いてセットできるので、タイムスケール２６２の解像度は、タイムスケール２３２の解像度に一致している必要はない。

図３は、２３２または２６２のようなタイムスケールの解像度を変更すると得られる利点を示している。図２に示す解像度で、スレッド４は、関数＿ＳＴＲＬＥＮで長時間期間を消費しているように見える。図３に示す解像度では、明らかであるように、スレッド４が関数＿ＳＴＲＬＥＮ内で消費している時間の一部は＿ｆｕｎｃｌなどの、他の関数へのコールで消費されている。

図３は、ユーザインタフェース２１０の別の側面も示している。マウス１４６（図１）を操作すると、イベントのグラフィカル表現のどこにでもカーソル３１２を置くことができる。ユーザインタフェース２１０にグラフィカルに示されたイベントの各々に関する追加情報を得ることができる。図３の例で、ユーザは、マーク３４４の上にカーソル３１２を置いている。ユーザは、マーク３４４の上でクリックするか、マーク３４４の上でカーソルを「ホバリング」するだけでインプットを与えることができる。このユーザのインプットに応答して、分析プログラム１３０は、そのマークに関する追加情報をテキストボックス３１０に表示することができる。テキストボックス３１０に表示される情報は、ユーザによって選択されたグラフィカルオブジェクトで表わされた特定イベントによって決まり、ＳＱＬイベント、ＯＳカーネルイベントまたはウェブサーバイベントを含む、望みのイベントに関する情報をディスプレイ上に表示することができる。

図４は、本発明の別の実施形態によるユーザインタフェース４１０を示す図である。この実施形態では、テキストビューフィールド４６０には、４３０₁、４３０₂および４３０₃などの複数のタブが設けられている。これらのタブの各々は、マウス１４６を操作してカーソルをタブの上に置き、そこでクリックすることによりユーザインタフェースを通して選択できる。タブの各々は、選択されると、テキストビューフィールド４６０内に異なる種類の情報を表示することができる。タブ４３０₁は、関数に関する集約情報を提示するが、この情報は、従来技術ではパフォーマンス分析システムによって提示されていたものである。タブ４３０₁が選択されると、テスト対象ソフトウェアプログラムの実行期間にコールされた関数をリストしたカラム４２０₁が表示される。隣接カラムには、カラム４２０₁にリストされた関数の各々に関する情報が表示される。例えば、カラム４２０₂は、テスト対象ソフトウェアプログラム１１０の実行期間に記録された関数に入った回数を示している。カラム４２０₃は関数内の総実行時間（ａｇｇｒｅｇａｔｅ ｅｘｅｃｕｔｉｏｎ ｔｉｍｅ）を示している。このタブに提示された情報は、集約または統計情報であり、そこに示されるイベントは発生順になっていない。

タブ４３０₂が選択されると、従来のパフォーマンス分析システムで表示されたコールツリーに類似したコールツリーが表示される。パフォーマンス分析システムによって生成できる、他のどのタイプのデータも、現時点で公知であるか、将来に開発されるかに関係なく、そのデータにアクセスするために選択できるタブを用意することによって、人間のユーザのために選択的に表示させることができる。タブ４３０₃をアクティブにすると、図３に示したようなイベントトレースを得ることができる。

図４は、ユーザインタフェース４１０の別の側面を示している。この例で、スレッドビューフィールド２３０は、図２に示す時間のサブレンジの後にある時間のサブレンジを示している。従って、タイムインジケータ２２６は、図２よりも時系列フィールド２２０内でさらに右に現れている。

図５は、ユーザインタフェース４１０のさらに別の側面を示している。スレッドビューフィールド２３０に示されたスレッドを、ユーザのインプットに基づいて選択することができる。ユーザがスレッドを選択できるようにすると、ユーザは異なるトレース内のイベントのグラフィカル表現を並置することによりパフォーマンス上の問題を特定するプロセスが容易化される。このようにすると、ユーザは、スレッド相互間の依存関係を特定し、これらの依存関係が原因で起こるパフォーマンス上の問題を特定することができる。

図５は、表示するスレッドをユーザに選択させるために使用できる１つのメカニズムの例を示している。この例で、ユーザインタフェース４１０は、メニューバー２１２上に選択エリア５１０を含んでいる。選択エリア５１０は、グラフィカルユーザインタフェースで従来から使用されているように、選択されたとき、リストボックス５１２をオープンするメニューアイテムとして実現することができる。

リストボックス５１２は、テスト対象プログラム１１０の中のスレッドのリストを含み、スレッドの各々にはその隣にチェックボックスが付いている。各チェックボックスは、コントロールの働きをし、選択されると、対応するスレッドをレッドビューウィンドウ２３０に表示されたスレッドのリストに組み入れる。

スレッド選択の他の側面は、ユーザインタフェース４１０内のコントロールを通して利用できる。例えば、コントロールを使用すると、ユーザはスレッドビューウィンドウ２３０内のスレッドの順序付けを指定することができる。

上述した特徴を使用すると、ユーザは、テスト対象プログラムのパフォーマンスデータを、マルチスレッドプログラム（ｍｕｌｔｉ−ｔｈｒｅａｄｅｄ ｐｒｏｇｒａｍ）の動的やりとり（ｄｙｎａｍｉｃ ｉｎｔｅｒａｃｔｉｏｎｓ）を即時に理解できるような形式に編成することができる。複数レベルで掘り下げること（ｄｒｉｌｌ ｄｏｗｎ）ができるので、パフォーマンスエンジニアまたは他のユーザは効果的なプロセスでプログラムについてパフォーマンスエンジニアリングを行なうことができる。代表的なシナリオでは、このプロセスには、詳しく調査する価値のあるプログラムの実行期間に時系列フィールド２２０を使用してサブ領域を特定することを含めることができる。例えば、集中的アクティビティまたは非常に少ないアクティビティが行なわれているサブ領域を特定して、詳しく調査することができる。

詳細調査するサブ領域が選択されると、そのサブ領域における特定のスレッドを調べることができる。ユーザは、タイムスケールを調整してスレッドビューフィールド２３０に表示するようにすると、シングルスレッドのある個所またはスレッド間のやりとりの組み合わせがプログラムの実行速度を低下させていた個所が特定しやすくなる。マーカやアクティビティバーのような、スレッドビューフィールド２３０におけるビジュアルインジケータを手引きとしてユーザは問題個所を特定することができる。

そのあと、ユーザは、いくつかのスレッドを選択してテキストビューウィンドウ４６０に表示するようにすると、これらスレッドの特定のやりとりに関するより詳細な情報を得ることができる。イベントを発生順に提示させることも、関数または他のプログラムエレメントの集約データを提示させることもできる。

ディスプレイエリアは、従来の多くのグラフィカルユーザインタフェースと同じように、ユーザがディスプレイの外観をカスタマイズできるように、オープンし、クローズし、最小化し、再位置付けすることができる。

ユーザインタフェースにおけるコントロールは、現時点で公知であるか、将来開発されるかに関係なく、適切であればどのような方法でも実現することができる。例えば、ソフトウェア開発環境には、拡張可能インタフェースがあるため、プログラムとのグラフィカルユーザインタフェースにメニューアイテムを組み込むことができることが多い。さらに、このような開発環境では、予め定義されたコントロールを、アプリケーション用にカスタマイズしたアクションと共に、グラフィカルユーザインタフェースに組み込むこともできる。スクロールバー、テキストボックスおよびドロップダウンリストなどのコントロールは、グラフィカルユーザインタフェースで使用されている、現時点で公知のコントロールの例であり、例えば、Ａｃｔｉｖｅ−Ｘオブジェクトして実現することができる。

動作時には、グラフィカルユーザインタフェース上に表示される情報は、適切であればどのような方法でも生成することができる。上述したように、イベントに関する情報はバッファに収集される。これらのバッファは、情報の即時処理ができるようにインデックスが付けられている。分析プログラム１３０は、この分野で公知のように集約データを計算することができる。また、分析プログラム１３０は、バッファ内の時間順の情報を使用して、の始まりと終わりを通知するイベントを特定することもできる。

分析プログラムは、Ｃ＋＋のような、任意の適当なプログラミング言語で作成されたプログラムにすることができる。これは、パフォーマンスエンジニアによって使用されるワークステーションに関連するプロセッサなどの、任意の適当なプロセッサに関連するコンピュータ可読媒体（ｃｏｍｐｕｔｅｒ−ｒｅａｄａｂｌｅ ｍｅｄｉａ）にストアしておくことができる。

以上、本発明の少なくとも１つの実施形態のいくつかの側面を説明してきたが、以上の説明から理解されるように、この分野の精通者には容易であるように、種々の変更、修正および改善を行なうことができる。

かかる変更、修正および改善は本明細書の開示内容の一部となるものであり、また本発明の精神と範囲に属するものである。従って、上述の説明と図面は単なる例示である。

本発明の上述した実施形態を実現するには、多数の方法を利用できる。例えば、これらの実施形態は、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの組み合わせを使用して実現することができる。ソフトウェアで実現されるときは、ソフトウェアコードは、そのコードがシングルコンピュータに用意されているか、あるいは複数のプロセッサ間に分散されているかに関係なく、任意の適当なプロセッサまたはプロセッサの集まり上で実行させることができる。

また、上述した種々のメソッドまたはプロセスは、種々のオペレーティングシステムまたはプラットフォームのいずれかを採用する１または２以上のプロセッサ上で実行可能なソフトウェアとしてコーディングすることができる。さらに、かかるソフトウェアは、いくつかの適当なプログラミング言語および／または従来のプログラミングまたはスクリプトツールのいずれかを用いて書くことができ、実行可能マシン言語コードとしてコンパイルすることもができる。

以上の観点において、本発明は、１または２以上のコンピュータまたは他のプロセッサ上で実行されたとき、上述した本発明の種々実施形態を実現するメソッドを実行する１または２以上のプログラムと共に符号化されたコンピュータ可読媒体（または複数のコンピュータ可読媒体）（例えば、コンピュータメモリ、１または２以上のフロッピディスク、コンパクトディスク、光ディスク、磁気テープ）として具現化することができる。１または２以上のコンピュータ可読媒体は、そこにストアされた１または２以上のプログラムが上述した本発明の種々側面を実現するために１または２以上の異なるコンピュータまたは他のプロセッサ上にロードされるようにトランスポート可能にすることができる。

「プログラム」という用語は、上述した本発明の種々側面を実現するようにコンピュータまたは他のプロセッサをプログラミングするために採用できる任意タイプのコンピュータコードまたは命令セットのことを指すために、ここでは広義の意味に用いられている。さらに、当然に理解されるように、本実施形態の一側面によれば、その実行時に本発明の方法を実行する１または２以上のコンピュータプログラムはシングルコンピュータまたはプロセッサ上に置いておく必要はなく、複数の異なるコンピュータまたはプロセッサ間にモジュール方式で分散させて本発明の種々側面を実現させることができる。

本発明の種々側面は単独で使用することも、組み合わせで使用することも、上記に説明した実施形態の中で明示的に説明しなかった種々の構成の中で使用することも可能であり、従って、本発明を適用する際には、上記説明の中で述べたまたは図面に図示したコンポーネントの詳細または構成に限定されない。例えば、ある実施形態の中で説明した側面は他の実施形態の中で説明した側面と、どのような方法でも組み合わせることができる。

クレームエレメントを修飾するためにクレームの中で「第１」、「第２」、「第３」などの序数を表わす用語が用いられているが、それ自体はあるクレームエレメントが他のクレームエレメントよりも優先または先行すること、またはある方法のアクトが実行される時間的順序を意味するものではなく、クレームエレメントを区別するために、ある名前をもつあるクレームエレメントを同じ名前をもつ別のエレメント（序数の使用を除く）から区別するために単なるラベルとして用いられたものである。

また、本明細書の中で用いられている言い回しまたは用語は説明目的のためであり、限定的なものではない。「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、「含むまたは備えた（ｃｏｍｐｒｉｓｉｎｇ）」、または「持つまたは有する（ｈａｖｉｎｇ）」、「収めた（ｃｏｎｔａｉｎｉｎｇ）」、「伴う（ｉｎｖｏｌｖｉｎｇ）」およびこれらの変形は、そのあとに列挙されたアイテムおよびその等価アイテムだけでなく、追加アイテムも包含するものである。

開発環境を示す概略図である。 図１の開発環境におけるユーザインタフェースを示す概略図である。 別の動作ステートにある図２のユーザインタフェースを示す概略図である。 図１の開発環境におけるユーザインタフェースの代替実施形態を示す図である。 別の動作ステートにある図４のユーザインタフェースを示す概略図である。

Claims (20)

1. ディスプレイとユーザインタフェースデバイスを含むグラフィカルユーザインタフェースを有するコンピュータシステムにおいて、テスト対象ソフトウェアプログラムに関するパフォーマンスの情報を表示する方法であって、前記テスト対象ソフトウェアプログラムは、各々が実行されるように構成された複数のスレッドにおいて実行されるように構成されているものにおいて、前記方法は、
   ａ）テスト対象ソフトウェアプログラムが実行されている期間のタイムレンジの表現を第１ディスプレイエリアに表示するステップと、
   ｂ）前記第１ディスプレイエリアに表示された前記タイムレンジの指示部分を示すユーザインプットを、ユーザインタフェースデバイスを通して受信するステップと、
   ｃ）複数のグラフィカルインジケータを第２ディスプレイエリアに表示するステップであって、各グラフィカルインジケータは、タイムレンジのサブレンジ期間の複数のスレッドの１つの実行でのイベントを表わしていて、前記サブレンジは、前記第１ディスプレイエリアに表わされたタイムレンジの指示部分を含んでいるものとを備えることを特徴とする方法。
2. ａ）前記第１ディスプレイエリアにおけるタイムレンジの表現は、グラフィカル表現を含み、
   ｂ）前記ユーザインタフェースデバイスは、ポインティングデバイスを含み、前記タイムレンジの指示部分を示すユーザインプットを受信するステップは、前記ユーザが前記ポインティングデバイスを使用して、前記タイムレンジの一部のインジケータをドラッグして、そのインジケータを前記タイムレンジの前記グラフィカル表現のロケーションでドロップしたことを検出することを含むことを特徴とする請求項１に記載の方法。
3. 前記テスト対象ソフトウェアプログラムは、アクティビティレベルと共に実行され、前記第１ディスプレイエリアは、前記テスト対象ソフトウェアプログラムの実行のアクティビティレベルのグラフィカル表現をさらに含んでいることを特徴とする請求項１に記載の方法。
4. 前記第２ディスプレイエリアのタイムスケールを示すユーザインプットを受信し、タイムスケールを示す前記ユーザインプットに応答して前記サブレンジを調整するステップをさらに備えることを特徴とする請求項１に記載の方法。
5. 前記第２ディスプレイエリアは、スクロールバーをさらに含み、前記方法は、前記スクロールバーを移動するためにユーザインプットを前記ユーザインタフェースデバイスを通して受信するステップと、前記第２ディスプレイエリアに表示された前記サブレンジを、前記スクロールバーを移動する前記ユーザインプットに応答して調整するステップとをさらに備えることを特徴とする請求項４に記載の方法。
6. 少なくとも１つのテキスト表現を第３ディスプレイエリアに表示するステップをさらに備え、前記テキスト表現は、複数のスレッドの１つの実行でのイベントであって、グラフィカルインジケータによって前記第２ディスプレイエリアに表わされたイベントの指示を含み、前記イベントは、前記スレッド内で行なわれた関数へのコールを含むことを特徴とする請求項１に記載の方法。
7. 前記テスト対象ソフトウェアプログラムは、前記テスト対象ソフトウェアプログラムの実行時に実行される関数を含み、第３ディスプレイエリアに表示するステップは、
   ａ）前記第３ディスプレイエリアに表示される前記テキスト情報の内容を指定するユーザインプットを受信し、
   ｂ）前記テキスト情報の内容を指定する前記ユーザインプットに応答して、前記テスト対象ソフトウェアプログラム内の関数の実行を特徴付ける集約情報を選択的に表示することをさらに含むことを特徴とする請求項６に記載の方法。
8. ａ）前記テスト対象ソフトウェアプログラムは、オペレーティングシステムを含むプラットフォーム上で実行されるアプリケーションプログラムを含み、
   ｂ）イベントを表わす複数のグラフィカルインジケータを表示することは、オペレーティングシステムの予め定められた部分または前記テスト対象ソフトウェアプログラムの予め定められた部分のどちらかへの関数コールの実行を示すことを含むことを特徴とする請求項１に記載の方法。
9. テスト対象ソフトウェアプログラムの実行期間に動作する複数のスレッドに関するパフォーマンスの情報がディスプレイデバイス上でレンダリングされて、前記テスト対象ソフトウェアプログラムの実行期間の時々に動作イベントが現れるようにしたものにおいて、前記パフォーマンスの情報は、前記複数のスレッドの各々について、
   前記スレッドの動作を表わすスレッドエリアを含み、前記スレッドエリアは少なくとも１つのインジケータをもち、各々のインジケータは、前記スレッドの動作イベントを表わしており、前記複数のスレッドの各々のスレッドエリアは、前記複数のスレッドの前記スレッドエリアにおけるインジケータが前記複数のスレッドの動作イベントの時間的相関関係をグラフィカルに示すような位置に置かれていることを特徴とするディスプレイデバイス。
10. 前記スレッドエリアの各々は、前記ディスプレイスクリーン上に延長領域を含み、前記複数のスレッドエリアの少なくとも一部内でインジケータは、前記スレッドエリアによって表わされた前記スレッドがブロックされて別のスレッドを待っているときのタイムレンジを表わしていることを特徴とする請求項９に記載のディスプレイデバイス。
11. 前記スレッドエリアの各々は、前記ディスプレイスクリーン上に延長領域を含み、前記複数のスレッドエリアの少なくとも一部内でインジケータは、前記スレッドエリアによって表わされた前記スレッドがアクティブであるときのタイムレンジを表わしていることを特徴とする請求項９に記載のディスプレイデバイス。
12. 前記スレッドエリアの少なくとも１つは、予め定められた関数が前記スレッドエリアによって表わされた前記スレッド内からアクセスされたことを表わすインジケータを含むことを特徴とする請求項１０に記載のディスプレイデバイス。
13. 前記テスト対象ソフトウェアプログラムは、オペレーティングシステム上で稼動するアプリケーションプログラムであり、前記予め定められた関数は、前記アプリケーションプログラム内の関数を含むことを特徴とする請求項１２に記載のディスプレイデバイス。
14. 前記スレッドエリアに隣接するタイムスケールエリアをさらに備え、前記タイムスケールエリアは、インジケータによって表わされた前記複数のスレッドにおける前記イベントと時間的に相関付けられていることを特徴とする請求項９に記載のディスプレイデバイス。
15. 時系列エリアをさらに備え、前記時系列エリアは、前記テスト対象ソフトウェアプログラムの実行期間の処理の集中度をグラフィカルに示していることを特徴とする請求項９に記載のディスプレイデバイス。
16. テキストエリアをさらに備え、前記テキストエリアは、少なくとも１つのスレッドの動作期間の、順序付けられたイベントのリストを含み、前記順序付けられたイベントのリストは、関数入口、関数出口およびＳＱＬイベント、ＯＳカーネルイベントおよびウェブサーバイベントからなるセットの中の少なくとも１つのイベントを含むことを特徴とする請求項９に記載のディスプレイデバイス。
17. テスト対象ソフトウェアプログラムのパフォーマンスを分析するためのコンピュータで実行可能なコンポーネントを有するコンピュータ可読媒体であって、前記テスト対象ソフトウェアプログラムは、複数のスレッドで実行されるように構成され、前記コンピュータで実行可能なコンポーネントは、
    ａ）前記テスト対象ソフトウェアプログラム内の前記複数のスレッドの実行に関するデータを収集するように構成されたデータ収集コンポーネントと、
    ｂ）前記収集されたデータを分析して、前記複数のスレッドに関する実行情報を導き出すように構成された分析コンポーネントと、
    ｃ）前記複数のスレッドの少なくとも一部分に関する前記実行情報を人間の目に見える形式で表示し、前記人間の目に見える形式は、前記一部分の中の前記複数のスレッドの各々の実行情報を時間の関数としてグラフィカルに表現したものを含み、前記一部分の中の複数のスレッドの各々の前記グラフィカル表現は、前記一部分の中の前記複数のスレッドの各々におけるイベントを、時間的に相関付けることを可能にするフォーマットで表示されるように構成された報告コンポーネントとを備えることを特徴とするコンピュータ可読媒体。
18. 前記報告コンポーネントは、前記複数のスレッドの少なくとも１つのグラフィカル表現を表示するように構成され、前記グラフィカル表現は、少なくとも１つのスレッドがいつブロックされて、前記複数のスレッドの中の別のスレッドからの応答待ちに置かれているかを示すインジケータを含むことを特徴とする請求項１７に記載のコンピュータ可読媒体。
19. 前記テスト対象ソフトウェアプログラムは、予め定められたイベントを実行できるオペレーティングシステムを含むプラットフォーム上で実行されるように構成され、前記報告コンポーネントは、前記一部分の中の前記複数のスレッドの少なくとも１つのグラフィカル表現を表示するように構成され、前記グラフィカル表現は、前記予め定められたイベントを実行するためにそのスレッドが前記オペレーティングシステムをトリガしたかどうかを示すインジケータを含んでいることを特徴とする請求項１８に記載のコンピュータ可読媒体。
20. 前記テスト対象ソフトウェアプログラムは、少なくとも１つのＡＰＩを含み、前記データ収集コンポーネントは、ＡＰＩがアクセスされたことを示すデータを収集するように構成され、前記報告コンポーネントは、前記一部分の中の前記複数のスレッドの少なくとも１つのグラフィカル表現を表示するように構成され、前記グラフィカル表現は、前記ＡＰＩが前記スレッド内でアクセスされたかどうかを示すインジケータを含んでいることを特徴とする請求項１８に記載のコンピュータ可読媒体。

Images