JP2009540463A - Ａｐｉ性能プロファイルを収集し報告するための自動化された方法およびシステム - Google Patents

Abstract

アプリケーションプログラミングインターフェース（ＡＰＩ）の性能を測定する方法が、ＡＰＩによって呼び出された機能のリストを生成するために、ターゲットＡＰＩを選択し、選択されたＡＰＩの機能呼出しのためのメモリ割当てを追跡するステップを含む。次いで、個々の機能がＡＰＩ内で別個に呼び出され、それぞれの機能についてのタイミングおよびメモリ割当てデータが収集され記録される。次いで、記録された結果が、ｌｏｇ₂メソッドに従ってバケット化され、特定のＡＰＩの性能を示すために、ＡＰＩユーザがアクセスできるようにされる。

Description

本発明は、アプリケーションプログラミングインターフェース（ＡＰＩ）の性能を測定する方法に関する。

他の工学専門分野とは異なり、ソフトウェアエンジニアは、設計上の決定を行うときに照会することができる定量的情報をほとんど有していない。アプリケーションプログラミングインターフェース（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）性能コストを列記したオムニバス形式のカタログ（ｏｍｎｉｂｕｓ ｃａｔａｌｏｇ）はない。この場合、用語「ＡＰＩ」は、ワシントン州Ｒｅｄｍｏｎｄの本件特許出願人から入手可能な「Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムＡＰＩ」に見られるような機能のファミリーではなく、「ＩｎｖａｌｉｄａｔｅＲｅｃｔ ＡＰＩ」に見られるような単一の機能を指す。

さらに、この状況は、ほとんどのＡＰＩがそのコストを単一の数によって特徴付けることができないという事実によって複雑になる。コストは、メモリ使用、ＣＰＵ使用、Ｉ／Ｏのコストなどの多くの異なるやり方で測定することができ、それは、入力パラメータ、ならびにコンテキスト、およびもちろん、使用可能なハードウェアに依存することがある。その結果、一般に、ＡＰＩの性能を特徴付ける試みは全くなされていない。これによって、エンジニアは、設計決定を行うときに使用可能なアプリオリな（ａ ｐｒｉｏｒｉ）手引きをもたないという恵まれない立場に置かれている。エンジニアは、プロトタイプを作成し、あるいはさらに悪いことには、コストに関する懸念事項を単に推測し、完全に無視し、またはうまく行くように単に願うことに頼らなければならない。これらの後者の選択は、非常によく見られることである。したがって、ＡＰＩデータの収集は、ＡＰＩ性能またはリソースコストについての有用な知識を提供するのに非常に望ましい。

したがって、ＡＰＩの動作についての非常に正確なメモリ割当ておよび実行時間データを収集することが望ましい。一目的は、ＡＰＩコンシューマの意図した用途に適したメモリおよびタイミング特性を特定のＡＰＩコンポーネントが有しているかどうかに関して、決定することができるように、そのデータをＡＰＩコンシューマに提供することであり得る。割当てとタイミングの両方が、機能がどのように使用されるかによって変化するので、データは、幅広い範囲の実在のシナリオについての割当ておよびタイミングの統計分布を反映し得ることが好ましい。この分布は「性能プロファイル」を構成することができ、この性能プロファイルは、ＡＰＩの振舞いのトラブルシューティングと、コンシューマに対するこれらの特性の文書化との両方を行うために使用してもよい。

メモリ割当ては、ほぼ１００％の精度で測定され得るが、実行時間の測定は、不安定さを伴う。測定自体は、実行時間全体のうちの一部を取り、その結果、データに歪みが生じる。これは、単一のプロファイリング実行で１組の相互依存する機能のタイミング特性を集める場合に特に当てはまる。コールツリーのより深くの機能呼出しの測定オーバーヘッドが累積し、コールツリーのより上位の機能の結果が変更される。たとえば、機能Ａはタイトループ内で機能Ｂを何千回も呼び出し、同じランでＡとＢのタイミングが測定される場合、Ｂの累積の測定コストによって、Ａの結果が劇的に変更されることがある。既存のツールは、累積の測定誤差を取り去ることによって問題に対処しようと試みるが、この手法は、統計的に有意な結果をもたらすことができていない。

一般に、既存のＡＰＩ測定法は、特定の実行に関する詳細なコスト情報を記録することができるプロファイリングツールのコンテキストで使用される。しかし、これらのシステムは、測定行為自体がコストの乱れを引き起こすので、オムニバス形式のデータ収集には適していない。それらは、単一のランでプログラム全体に関する情報をできるだけ多く得るように設計されている。様々な実行にわたる特定のＡＰＩに関する情報を収集することが望ましい。本発明は、これらおよび他の問題に対処する。

この課題を解決するための手段は、下記の発明を実施するための最良の形態でさらに述べる選択された概念を簡略化された形で述べるために提供されている。この課題を解決するための手段は、特許請求された主題の主な特徴または本質的な特徴を識別することを意図しておらず、また特許請求された主題の範囲を限定するために使用することも意図していない。

一実施形態では、アプリケーションプログラミングインターフェース（ＡＰＩ）の性能を測定する方法が、ＡＰＩによって呼び出された機能のリストを生成するためにターゲットＡＰＩを選択し、選択されたＡＰＩの機能呼出しのためのメモリ割当てを追跡するステップを含む。次いで、タイミングおよびメモリ割当てデータを測定するために、個々の機能が別個に呼び出される。次いで、記録された結果が、ｌｏｇ₂メソッドに従ってバケット化され、特定のＡＰＩの性能を示すために、ＡＰＩユーザがアクセスできるようにされる。

別の一実施形態では、ユーザのマシン内に常駐するランダムに選択されたＡＰＩの性能情報を収集する分散型の方法が、プロファイラシステムによって可能になる。プロファイラシステムは、自発的なユーザに配布され、ユーザのコンピュータ上のアプリケーションのＡＰＩ性能を非干渉ベースで測定する。収集されたデータは中央ストレージサービスに転送され、この中央ストレージサービスで、ＡＰＩ情報が収集され、多くのＡＰＩの性能を表す情報のバケットへと編成される。この情報は、ソフトウェア開発者など、一般的なＡＰＩユーザが使用できるようにされる。

例示的な実施形態
ＡＰＩ性能プロファイラ
一実施形態では、ＡＰＩ性能プロファイルを収集し報告するための自動化された方法およびシステムが提供される。この実施形態は、アプリケーション開発の助けとするために開発者またはツールによって使用することができる性能プロファイルまたはフィンガープリントを生成するために、実行コードの非常に正確で経験的な観察値を収集することに焦点を当てている。この自動化された方法は、専門の性能プロファイラ、公に目に見えるすべての入口点についてのデータを生成するためにバイナリを網羅的に実行する自動化システム、解析ツールによって消費され得る形でこのデータを持続させるための機構、ならびに機能性能特性を理解する助けとするためにプロファイルをグラフィカルにレンダリングするためのシステムの使用を用いる。あるモードでは、プロファイラは、目に見えるＡＰＩについての正確な実行時間情報を収集する。別のモードでは、プロファイラは、いずれかの機能を呼び出すと生じるメモリ割当てに関する詳細を収集する。

図１は、ＡＰＩ性能を測定するためにコンピューティングプラットフォーム上で実行され得るＡＰＩプロファイラのための例示的なソフトウェアアーキテクチャ１００を示している。こうした一システムは、共通言語インフラストラクチャのためのＥＣＭＡ ３３５規格のＭｉｃｒｏｓｏｆｔ（登録商標）ＣＬＲ（商標）実装である。テスト対象のＡＰＩ １０２は一般に、観察および記録のためにインストルメント化され得る（ｉｎｓｔｒｕｍｅｎｔ）その場特性を示す。ＣＬＲ（商標）と互換があり得るメモリ割当てプロファイラ１０４は、所与のＡＰＩ性能シナリオを実行し、そのメソッドへの機能呼出しが、割り当てられたバイト数のｌｏｇ₂の離散値をもたらした回数のカウントを記録する。メモリ割当てプロファイラは、包含的割当て値と排他的割当て値を別々に測定し記録する。包含的メモリ割当て値は、それが呼び出した機能によって割り当てられたメモリのすべてを含めた、機能によって割り当てられたバイト数である。排他的メモリ割当て値は、機能自体の一部であるコードのブロック内に割り当てられたバイト数である。

タイミングプロファイラ１０６は、ＣＬＲ（商標）とも互換性があり、追加入力として指定された、メソッドのジャストインタイム（ＪＩＴ：Ｊｕｓｔ ｉｎ Ｔｉｍｅ）コンパイルにそれ自体をつなぐ。ランの間の追加のオーバーヘッドだけが、調査されている特定のメソッドへの呼出しのために生じており、他のメソッドへの呼出しのオーバーヘッドは生じないようなやり方で行われる。タイミングプロファイラは、テスト対象ＡＰＩ １０２に関するタイミング情報をも測定し記録する。

調整モジュール１０８は、入力として、所与のマネージドコードシナリオを実行するためのスクリプトを取り、スクリプトを使用してテスト対象ＡＰＩ １０２に対して割当てプロファイラ１０４をまず実行する。次いで、調整モジュールは、割当て段階でどのメソッドが実行されたかについての情報を使用して、タイミングプロファイラ１０６の下でシナリオを繰り返し再実行する。また調整モジュールは、タイミングプロファイラ１０６が、同じランにおいて相互依存する機能のタイミングを測定するように決して指示されないことを保証する。換言すると、調整モジュールは、同じ呼出しスタックに現れ得るいずれか２つの機能を同時に測定しないことによって、いずれの実行スレッド上においても多くて１つの測定が進行中であることを保証する。したがって、テスト対象ＡＰＩ １０２の真の性能を隠し得る２次機能は測定されず、記録されない。本発明の一態様では、同じ呼出しスタックに決して現れない機能が、同時に測定され記録されてもよい。たとえば、３の機能Ａ、Ｂ、Ｃが与えられ、機能ＡとＣだけが同じ呼出しスタックに現れる場合、ＡとＣは、同時に測定されず、記録されない。しかし、機能ＡとＢは、機能ＢとＣと同様に、同時に記録することができる。

併合ツールモジュール１１０は、メモリ割当てプロファイラ１０４およびタイミングプロファイラ１０６のすべてのランからの結果を組み合わせて、各テスト対象ＡＰＩ １０２の単一の結果テーブル１１２にする。特定のテスト対象ＡＰＩ １０２の結果テーブルは、包含的および排他的メモリ割当てのｌｏｇ₂バケット化、ならびに実行時間のｌｏｇ₂バケット化を示すことができる。併合ツールモジュールは、テスト対象ＡＰＩ １０２の幅広い範囲の使用を表すテーブルを生成するために、複数の異なるランからの結果を組み合わせるのに使用することもできる。したがって、単一の実行統計、ならびに複数の呼出し統計が、テスト対象ＡＰＩ １０２に関して集められてもよい。

任意のテスト対象ＡＰＩ １０２の結果テーブル１１２データを各機能のヒストグラムにレンダリングするためのグラフィカルユーザインターフェース１１４は、開発者が、所与のテスト対象ＡＰＩ １０２を構成する機能の性能特性に関する推論を行うことを可能にする。一実施形態では、特定のテスト対象ＡＰＩ １０２の結果テーブル１１２内の集められたＡＰＩ性能情報は、ｌｏｇ₂メソッドを使用して大きさの順序に編成されまたはバケット化されてもよい。さらに、ＡＰＩ性能プロファイルは、データの解析によって作成されてもよい。

これらの性能プロファイルは、ＡＰＩ所有者とＡＰＩコンシューマの両方に、有益な情報を伝達する。プロファイルは、たとえば、ＡＰＩを使用し始めるためのスタートアップコストがあり、その後、後続の呼出しはメモリ消費を伴わないことを示し得る。別のプロファイルは、メモリ割当てと実行時間の両方が、ＡＰＩ呼出しに提供されるデータに対する線形または他の関係で増加することを示し得る。これらのプロファイルは、ＡＰＩ開発者へのＡＰＩ製品品質を保証し、または特定の所望の性能特性を満たすべき新しいＡＰＩを開発するために解析し分類することができる。

非限定的な一実施例として、ＡＰＩ Ｏｂｊｅｃｔ．ＥｑｕａｌｓまたはＧｅｔＨａｓｈＣｏｄｅ（）オーバーライドなど、性能の影響を受けやすいコードが、本発明の態様を使用して特徴付けられ、プロファイリングされ得る。開発者など、これらのＡＰＩのユーザは、プロファイリングされたＡＰＩがその設計において有する性能を予測するために、公表されたプロファイル情報にアクセスすることによってグッドデザインを実践することができる。

一部の実施形態では、図１のソフトウェアアーキテクチャモジュールは、ネットワーク接続されたコンピュータからのダウンロード、またはそれに限らないが、ＣＤ−ＲＯＭなどのコンピュータ読取り可能媒体を介して実行するためにコンピュータに提供されてもよい。ダウンロードの後、図１のコンピュータアーキテクチャまたはモジュールは、実行待機して、コンピュータＲＡＭに常駐してもよい。

本発明の一態様では、ＡＰＩプロファイラは、タイミングデータが、単一パスで達成され得る精度よりも高い精度で集められることを保証するために、同じＡＰＩ実行シナリオを通る複数のパスを使用することができる。図２は、ＡＰＩプロファイラの例示的な方法を示すフローチャート２００である。
最初、ＡＰＩプロファイラに、特徴付けるべきターゲットＡＰＩが与えられる（ステップ２０２）。次いで、メモリ割当てプロファイラは、ＡＰＩによって呼び出されたすべての機能のメモリ割当てを追跡するモードで実行される（ステップ２０４）。その結果、テスト対象ＡＰＩによって呼び出されたすべての機能のリストが生成される（ステップ２０６）。

このリストが取得されると、次いで、このシステムは、リスト内の各機能につき１回、シナリオを再実行し、他のすべての機能とは完全に別に各機能のタイミングを測定する（ステップ２０８）。それぞれの機能実行について、パラメータのタイミングおよびメモリ割当てデータが、ＡＰＩプロファイラによって集められ、結果が記録される（ステップ２１０）。このステップは、所与のランで追跡されている個々の機能について生じるオーバーヘッドだけを測定する効果を有する。この利点は、コールツリーのより深くにある機能によってもたらされる累積誤差がないということである。

一代替実施形態では、この方法は、ＡＰＩプロファイラが、単に割当て段階で機能リストを集めるのではなく、スタック上にどの機能が一緒に現れ得るか、またどの機能が現れ得ないか計算することもできるように一般化されてもよい。次いで、ラン当たり１つよりも多くの機能を測定し、依然として同じ高精度を保証することが可能になる。次いで、ＡＰＩ実行からのメモリおよび割当て情報は、呼出しスタックグループと併合して、提示のための結果テーブルにすることができる。一実施形態では、提示は、各機能または機能群のヒストグラムによって行われてもよい。

個々のランからの性能が記録されると、提示のために、別個の結果が処理される（ステップ２１２）。このステップの一環として、ＡＰＩプロファイラは、各機能への各呼出しについて現在のランで何が測定されているかに応じて実行時間または割当てバイトのｌｏｇ₂を追跡し続けることによって、タイミングおよびメモリ割当ての可能な値の範囲を表現してもよい。各ｌｏｇ₂エントリは、メモリ割当てまたは実行時間が同じｌｏｇ₂値を有する呼出しのバケットのカウントを増分するために使用される。次いで、別個のランのすべてからの結果が、一緒に併合される（ステップ２１２）。最終結果は、メモリ割当ておよびタイミングの各離散ｌｏｇ₂値のカウントを含む、シナリオにおけるすべての機能のテーブルである。幅広い範囲のシナリオにおけるＡＰＩの機能のより代表的なビューを得るために、複数のシナリオからの結果を併合することも可能である。

非限定的な一実施形態では、ＡＰＩ性能データ収集メソッドの擬似コードは、以下のとおりである。

上記の擬似コード例では、タイミングおよび割当てのパラメータは、測定されるパラメータが測定プロセスによって過度に妨げを受けない限り、ディスクＩ／Ｏ、ネットワーク使用、またはＡＰＩの影響を受ける他の任意のパラメータの測定を行うことができるように増大することもできる。

上記の例示的な擬似コードでは、ｌｏｇ₂（ｎ）は、ｎの２を底とする対数より小さい、またはそれに等しい最大整数を意味することに留意されたい。バケット内のデータを特徴付けることは、ＡＰＩの性能をバケット内に置くことをも含み得る。本質的に、測定されたパラメータは、「２のべき乗のバケット」をもたらすために、ｌｏｇ₂を使用して、切り捨てて最も近い整数に丸められる。これは、２進表現で最上位ビットの位置を見つけ、性能のカテゴリとして適切なバケットにデータを置くことによって実施することができる。さらに、測定されたパラメータの平均、中間および標準偏差などの基本統計値が計算され得るように、和、および平方和がバケット化される。こうした統計によって、ユーザに、測定されたＡＰＩの性能に関する関連情報が提供される。

非限定的な実施例において、以下のプログラムを仮定する。

ＡＰＩデータプロファイラを使用して、プログラム全体が、割当てプロファイラによって実行され、以下の呼出しシーケンスを１００回見る。

その間、表１と同様に、以下のバケット化データが集められる。分かりやすくするために、表１には、機能Ａ、ＢおよびＣの割当てのカウントだけが示されている。これらの機能の和および平方和のバケット化計算は、同様のやり方で計算することができる。

表１のバケットは、割り当てられたバイトのｌｏｇ₂で表現されており、またＡ、Ｂ、Ｃだけがそれぞれ、シナリオによって呼び出され、したがって、プログラムは、タイミングプロファイラを使用して３回、すなわち各機能につき１回再実行され得ることに留意されたい。第１のランでは、機能Ａだけが実行される。Ａへの３００回の呼出しの間、実行に２０から４０の間のクロックサイクルを要し、表２の機能Ａについて以下を得るたびにｌｏｇ₂を取り、バケットを増分することが観察されることに留意されたい。

表２のバケットは、ＣＰＵサイクルのｌｏｇ₂で表現されている。次の２つのランで、ＢおよびＣが、排他的に実行される。次いで、３つのランの併合が行われ得る。このプロセスは、研究所、開発環境、または実行時ユーザ環境内の多くのシナリオで実行されてもよく、収集されたデータはすべて、共通機能にバケットカウントを単に加えることによって一緒に併合されてもよい。これは、研究所、開発環境、または実行時ユーザ環境内で実行される１組の固定のシナリオからＡＰＩプロファイルを構築する１つのやり方を表している。次いで、図１のユーザインターフェース１１４は、検査のためにバケット化されたデータをレンダリングするために使用されてもよい。

バケット化されたデータは好ましくは、測定され記録されたＡＰＩデータに設計者がアクセスできるように公表される。たとえば、収集されたＡＰＩデータは、リモートアクセスを有する中央データベースなど、中央位置に収集されてもよい。代わりに、ＡＰＩデータは、コンピュータ読取り可能媒体または紙のカタログの形で作成され、ユーザに配布されてもよい。一般に知られている任意の公表および普及スキームが、公開のために使用されてもよい。

本発明の別の態様では、結果の理解が容易になるように、要約されたデータをユーザインターフェース上で視覚化することが遂行される。たとえば、収集され集約されたＡＰＩ測定データの結果は、各バケット内のカウントを要約するヒストグラムとして描かれてもよい。代わりに、結果は、より高コストのバケットに対応するホットエンド、およびより寒色のより安価なエンドに向かう色セグメントを有するカラースペクトルを使用して描かれてもよい。色の強度または棒の厚さは、そのバケット内のサンプルの数に対応する。

ＡＰＩデータの分散型収集
本発明の一態様では、ＡＰＩデータは、分散されたやり方で収集されてもよい。分散型ＡＰＩデータ収集の一目的は、開発者およびユーザがいずれかの１つのＡＰＩを使用するコストを査定する助けとするためにＡＰＩの性能のデータベースを作成することである。データベースにデータを取り込むために「ユーザ環境（ｉｎ ｔｈｅ ｗｉｌｄ）」ＡＰＩ性能の実際の測定値の統計的に興味深いサンプルを収集することが望ましい。データが取り込まれたデータベースは、一般的なハードウェア上で一般的な実際のアプリケーションにおいて観察される一般的な「性能コスト」を性能パラメータが反映している場合、価値が高くなる。したがって、ユーザマシン上で実際に使用されるＡＰＩの性能が望ましい。次いで、このデータ収集プロセスを使用して、実行時間、メモリ割当ておよびディスクＩ／Ｏなど、様々な異なる「リソースコスト」の性能コストの特性分布を生成することができる。

ユーザマシン上でＡＰＩ性能を測定することに付随する性能コストまたはオーバーヘッドを最小限に抑えるために、少数のＡＰＩだけが所与のいずれかのランで測定され、これらのＡＰＩがランごとにランダムに選ばれることが望ましい。一般には、１度に１つのＡＰＩだけが測定されてもよい。一実施形態では、ＡＰＩデータ収集は、自発的なユーザオプトインに基づき、様々なシステム上で行うことができる。これによって、様々なハードウェア上で時間をかけて収集されたＡＰＩのランダムサンプルが作成される。データは、中央サーバに合わせて周期的に更新することができ、この中央サーバでは、ＡＰＩ性能のデータベースが、追加の匿名データを伴って増大する。

図３は、ユーザのコンピューティング装置上で実行されるＡＰＩから分散データを収集するために使用され得る方法３００のフローチャートである。ユーザは、データ収集に参加するために、ＡＰＩデータの収集および提出を実施にする適切なプロファイラシステムプログラム、または１組のモジュールをまずインストールしなければならない。ユーザが、求められ、収集プロセスに同意し、またはそれを選ぶと仮定する。一実施形態では、多くのユーザは、収集スキームを選び、提供されるデータは、広範囲のＡＰＩデータの集合をもたらす多様な１組のユーザ、アプリケーションおよびマシンのからのデータである。最初、ユーザは、非干渉ベースでＡＰＩを測定することを可能にするために、ＡＰＩプロファイラソフトウェアモジュールをダウンロードし、または別のやり方でインストールし構成する（ステップ３０２）。必要な実行可能ファイルは、インターネットからダウンロードし、ローカルにインストールしてもよく、あるいはＣＤ−ＲＯＭまたは等価のプログラムデータ記憶媒体を介して取得してもよい。さらに、次いでＡＰＩプロファイラは、インターネットから配信されたソフトウェアにとって通常通りにサービスを受ける。ステップ３０２は、１度だけ実施する必要があり、後続のすべてのデータ収集セッションは、ステップ３０４で開始することができる。

実際にデータを集めるために、データ収集システムは、ユーザがいずれかの実行可能プログラムを実行するときはいつでも、それ自体をアクチベートしなければならない。この時、ＡＰＩプロファイラデータ収集システムは、監視するＡＰＩをランダムに選び、データを収集する（ステップ３０４）。次いで、選択されたＡＰＩへの呼出しがインターセプトされ、コストは、時間、ディスク操作、ネットワーク、メモリなど、１つまたは複数の次元で測定される。

一実施形態では、ＡＰＩのランダム選択は、当業者には知られている技術を使用して行われてもよい。使用される特定のランダム選択技術は、ＡＰＩプロファイラ収集ソフトウェアが実施される特定の実行時環境に依存してもよい。たとえば、ＮＥＴ（商標）共通言語ランタイム（ＣＬＲ（商標）：Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ）では、メソッドがＪＩＴコンパイルされるたびに乱数を生成するために、ジャストインタイム（ＪＩＴ）コンパイラの調整が行われてもよい。乱数が固定の閾値より小さい場合は、ＪＩＴコンパイラは、メソッドへの呼出しが次いでインターセプトされ、ＡＰＩプロファイラによって測定されるようにメソッドをインストルメント化してもよい。多くのこうしたランダム化選択技術が、所与の状況におけるＡＰＩ選択のために実装されてもよい。当業者は、本発明で目標とするために選択する特定の技術に基づいて、適切なランダム選択手法を選択し得る。

選択されたＡＰＩへの機能呼出しのインターセプト技術もまた、当業者にはよく知られており、数多くある。類似のインターセプトは、新しいオペレーティングシステム内で「ａｐｐ ｃｏｍｐａｔ ｓｈｉｍｓ」としても知られているアプリケーション互換性についての特別な振舞いを提供することが既に生じている。この同じシステムは、測定フックを挿入するために使用することができる。この場合もやはり、実際の測定が、既存のプロファイリングシステムによって既に使用されているよく知られている技術を使用して得られる。

データ収集の性能コストは好ましくは最小限に抑えられ、それを行うために使用される複数の技術があることに留意されたい。一実施例では、収集システムは、ユーザシステムへの影響を最小限に抑えるために、システム負荷または他の構成パラメータに基づいて、いずれかのデータの収集を控えてもよい。一実施例は、固定の少数のプログラムよりも多くのプログラムが同時にインストルメント化されることを防ぐシステムである。たとえば、せいぜい６つのバイナリのデータ収集が、１つの設定であってもよい。この数は、さらなるダウンロードによって動的に調整することができる。

選択されたＡＰＩが測定された後、次いで、各プログラム実行の終わりに、要約され、収集されたデータは、後の提出に備えてディスクに書き込まれてもよい。収集されたデータの量が決定され、十分なデータが選択されたかどうか判定するためにテストされてもよい（ステップ３０６）。十分なデータが収集されている場合は、データは、たとえばネットワークを介して送信することによって中央サービスに提出されてもよい（ステップ３０８）。たとえば、記録されたデータが、配信されるべき適度なアップロード時間で妥当なデータバッチを可能にするのに適したサイズ（〜１２８ｋ）に達する場合、ウェブサービスは、連絡を受けてもよく、ユーザの要約されたＡＰＩ性能情報が、中央サービスにアップロードされる。代わりに、より多くのＡＰＩ収集データがローカルに収集され得る場合、このプロセスは、ステップ３０４に戻ることができ、このステップ３０４では、次のＡＰＩがランダムに選択される。

次いで、中央サービスは、所与のユーザが情報を与えた各ＡＰＩに各カテゴリの新しいカウントおよびコストを加えることによってアップロード要求に応答してもよい。これは、新しいＡＰＩ性能データが中央サービス結果データベースに追加される集約（ステップ３１０）として知られている。したがって、結果データベースは、新しい情報で常に更新される。一実施形態では、バッチ処理を回避するために、付加的な統計の使用が用いられる。一実施形態では、「ユーザに呼び出されたユニークＡＰＩ平均」などの情報を追跡することは、結果の新しいバッチが追加されるたびに、時間のかかる既存データの再処理を必要とするので、これを行わないことが好ましい。

本発明の一態様では、中央データベースは、複数の媒体によってユーザに公表することができる（ステップ３１２）。たとえば、データベースは、インターネットまたは他のネットワーク接続を介して遠隔からアクセスしてもよい。ユーザが最新の性能コスト情報を有し得るように、データベース全体を周期的にリフレッシュすることが望ましい。すべてのユーザを同時に更新する必要があるとは限らず、また結果のデータベース全体を配信する必要があるとは限らない。一実施形態では、ユーザは単に、中央サービスの結果データベースの小さい部分に毎日照会することができ、ユーザは、コンテンツを増分的にリフレッシュしているデータを順に見る（ｒｏｔａｔｅ ｔｈｒｏｕｇｈ）。任意選択で、ユーザが望むならば、結果データベース全体をダウンロード可能にすることができる。データベースをバイナリフォーマットで直接公表することに加えて、コンテンツは、以下に示されるように、様々なやり方で直接的および間接的に使用することができる。

本発明の一態様では、ユーザは、収集されたＡＰＩ性能データのコンシューマである（ステップ３１４）。ユーザは、多くの目的のために、様々なやり方でデータにアクセスしてもよい。有用な使用モードの例について、ＡＰＩプロファイラシステムの有用性を示して、以下に概説する。
１）標準のＡＰＩ参照は、グラフィカルと、数字の形で詳細を見るのに使用可能な「ドリルダウン」との両方で表示する、ＡＰＩプロファイラ結果データベースに含まれた情報を自動的に含む。
ａ．文書フォーマッティングシステムが、各ＡＰＩの文書を作成する。
ｂ．各ＡＰＩについて、それが作成されるときに、ＡＰＩ性能コスト要約を取得するためにＡＰＩプロファイラデータに照会する。
ｃ．性能コスト要約が、リンクと共に、グラフィカルな形で文書内に挿入され、このリンクは、収集されたＡＰＩ性能データのウェブベース公表において詳細な形で最新データまで「ドリルダウン」することを可能にする。
２）Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（商標）システムのＩｎｔｅｌｌｉｓｅｎｓｅ（商標）特徴などの設計時間コーディング支援は、一般的なコストが直ちに目に見えるように、新しいＡＰＩ呼出しがコーディングされているとき、任意選択のドリルダウンを伴うグラフィカルな形のコスト要約を含むことができる。
ａ．このシステムは、１組の可能なＡＰＩ完了を引き起こす。
ｂ．各完了について、このシステムは、収集されたＡＰＩプロファイラデータに照会する。
ｃ．システム表示はそれぞれ、ＡＰＩプロファイラによって収集された情報からの要約をグラフィカルな形で提示する。
３）コードプロファイリングシステムの診断部分は、ＡＰＩプロファイラによって収集されたデータに照会して、所与のいずれかのユーザのＡＰＩ使用が、一般的な使用パターンにコスト的に匹敵するかどうか確認する。トラブルシュート体験を向上させるために、異常なコストは、疑わしいとしてユーザに報告されてもよい。
ａ．プロファイル内の観察された各ＡＰＩについて、このシステムは、ＡＰＩプロファイラ結果に照会する。
ｂ．それぞれのＡＰＩについて、観察されたコスト分布が、「置換テスト」などの標準の統計方法を使用して、ＡＰＩプロファイラ結果分布と比較される。
ｃ．ユーザコスト分布がＡＰＩプロファイラ収集データの分布よりも悪いという統計的証拠があることを統計法が示唆する場合、当該のＡＰＩは、潜在的な改良点としてフラグが立てられ、調査のためにユーザに提示される。
ｉ．提示は、それが呼出しスタック内に現れる場合にＡＰＩを強調表示することによって、または
ｉｉ．こうしたＡＰＩのリストの作成することによって、または
ｉｉｉ．観察された最高のコストをＡＰＩが有するコンテキストを強調表示することによって行うことができる。
４）ＡＰＩベンダは、これらの技術を使用して、顧客の一般的な使用およびコストに関する内部調査を作成して、それによってＡＰＩの改良を目標とし、その成功を追跡してもよい。
ａ．コストの分布は、発生モジュール、名前空間またはその両方によって細分して、レポート形式で生成することができる。
ｂ．次いで、これらの内訳は、計画作成のために、組織によって消費される。

本発明の一態様では、上記で言及されたように、ＡＰＩプロファイラは好ましくは、ユーザシステムが測定されているときに低性能の影響が加えられるように動作する。単一のプログラム実行の間、測定されたいずれかの特定のＡＰＩが何百万回も呼び出され、潜在的にはさらにハードウェア改良を伴い得ることを考慮すると、ＡＰＩコストが、さらなる解析に適した経済的な形に保たれることが重要である。所与のセッションにおける測定対象の各ＡＰＩに固定のサイズのエントリを有することが望ましい。しかし、大きな変化を伴うコスト分布を捕捉することも望ましい。これを達成するために、１つの手法では、正確なコストを捕捉するのではなく、分類された「バケット」内のコストカウントを追跡する。

上記に説明されたように、バケットは、性能またはリソースコストの、増加する各２のべき乗について作成される。それは、１、２、４、８以上のコストなどについて１つのバケットである。それぞれのコストバケットでは、中間値および分散値を増分的に計算することを実施するために、通常の統計累積が追跡される。すなわち、サンプルのカウント、コストの和、およびコストの平方の和が計算される。これらの値は、様々な精度で保持することができる。たとえば、カウントについては６４ビットの整数、他の２つの各統計については倍精度浮動小数点数が使用される。さらに、全体の平均値および分散値が提供され得るように、すべてのサンプルについての合計カウント、累計、および平方の累計が維持される。この手法によって、必要な分布情報を依然として保ちながら、集約されたデータのコストが制限される。さらに、これらのデータはすべて加法的であり、したがって、単純な加算によって、異なるランまたは異なるコンピュータからのサンプルと容易に組み合わせることができる。

一実施形態では、測定された時間は好ましくは、サイクルカウントなど、使用可能な高分解能タイマの標準単位で維持される。これによって、計算時間が節約され、ディスクに残されている最高品質時間がもたらされる。

本発明の一態様として、コンピュータ読取り可能媒体、たとえば、それだけに限らないが、磁気記憶装置、ＣＤおよびＤＶＤ媒体などの光学装置を使用して、上記に説明され、または本明細書に示唆された方法を実施することができるコンピュータプログラム命令を格納してもよい。こうしたコンピュータ媒体は、それが本発明の態様を実施することを可能にするために汎用コンピュータ上で使用する実行可能命令を保持すると考えられる。

本主題は、構造的特徴および／または方法論的行為に特有の言語で述べられているが、添付の請求項の範囲中に定義された本主題は、上述の特定の特徴または行為に必ずしも限定されないことを理解されたい。より正確に述べると、上述の特定の特徴または行為は、特許請求の範囲を実施する例示的な形として開示されている。

例示的なコンピューティング装置
図４および以下の説明は、媒体記憶装置とインターフェースするのに適したホストコンピュータについて簡潔に概説することを意図している。以下では汎用コンピュータについて説明されているが、これは、単一プロセッサの一例にすぎず、複数のプロセッサを備えたホストコンピュータの実施形態が、ネットワーク／バス相互運用性および相互作用を有するクライアントなどの他のコンピューティング装置と共に実装されてもよい。

必須ではないが、本発明の実施形態は、装置またはオブジェクトに関するサービスの開発者が使用するためにペレーティングシステムを介して実施し、および／またはアプリケーションソフトウェア内に含めることもできる。ソフトウェアは、クライアントワークステーション、サーバまたは他の装置など、１つまたは複数のコンピュータによって実行されているプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明することができる。一般に、プログラムモジュールは、特定のタスクを実施し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などを含む。一般に、プログラムモジュールの機能性は、様々な実施形態において要望に応じて組み合わせ、または分散させてもよい。さらに、本発明の様々な実施形態が他のコンピュータ構成で実施されてもよいことが当業者には理解されよう。使用に適し得るよく知られている他のコンピューティングシステム、環境および／または構成の例には、それだけに限らないが、パーソナルコンコンピュータ（ＰＣ：ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ）、現金自動預け払い機、サーバコンピュータ、手持ち型またはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラマブル家電、ネットワークＰＣ、器具、照明、環境制御要素、ミニコンピュータ、メインフレームコンピュータなどが含まれる。本発明の実施形態は、通信ネットワーク／バスまたは他の伝送媒体を介してリンクされたリモート処理デバイスによってタスクが実施される分散コンピューティング環境内で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含めてローカルとリモートの両方のコンピュータ記憶媒体内に置くことができ、クライアントノードは、サーバノードとして振る舞うことができる。

図４を参照すると、例示的なホストコンピュータを実装するための例示的なシステムが、コンピュータシステム４１０の形の汎用コンピューティング装置を含んでいる。コンピュータシステム４１０の構成要素は、それだけに限らないが、処理装置４２０と、システムメモリ４３０と、システムメモリを含めて様々なシステム構成要素を処理装置４２０に結合するシステムバス４２１とを含んでもよい。システムバス４２１は、メモリバスまたはメモリコントローラ、周辺バスおよび様々なバスアーキテクチャのいずれかを使用したローカルバスを含めて、複数のタイプのバス構造のいずれかであり得る。

コンピュータシステム４１０は一般に、様々なコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータシステム４１０によってアクセスすることができる任意の使用可能な媒体を含むことができ、揮発性と不揮発性、取外し可能と取外し不可能の両方の媒体を含む。限定するためではなく、例を挙げると、コンピュータ読取り可能媒体には、コンピュータ記憶媒体および通信媒体が含まれ得る。コンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造体、プログラムモジュールまたは他のデータなどの情報を格納するための任意の方法または技術で実装された揮発性と不揮発性、取外し可能と取外し不可能の媒体を含む。コンピュータ記憶媒体には、それだけに限らないが、ランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、読取り専用メモリ（ＲＯＭ：Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、電気的消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ：Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリまたは他のメモリ技術、コンパクトディスク読取り専用メモリ（ＣＤ−ＲＯＭ：Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、再書き込み可能コンパクトディスク（ＣＤＲＷ：ｃｏｍｐａｃｔ ｄｉｓｃ−ｒｅｗｒｉｔａｂｌｅ）、デジタル多用途ディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）または他の光ディスクス記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶または他の磁気記憶装置、あるいは所望の情報を格納するために使用することができ、またコンピュータシステム４１０によってアクセスすることができる任意の他の媒体が含まれる。

システムメモリ４３０は、読取り専用メモリ（ＲＯＭ）４３１およびランダムアクセスメモリ（ＲＡＭ）４３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。起動時などにコンピュータシステム４１０内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム（ＢＩＯＳ：ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）４３３は一般に、ＲＯＭ ４３１に格納される。ＲＡＭ ４３２は一般に、処理装置４２０によって直ちにアクセス可能であり、および／またはそれによる操作を現在受けているデータおよび／またはプログラムモジュールを含む。限定するためではなく、例示するために、図４は、オペレーティングシステム４３３、アプリケーションプログラム４３５、他のプログラムモジュール４３６およびプログラムデータ４３７を示している。

コンピュータシステム４１０は、他の取外し可能／取外し不可能、揮発性／不揮発性のコンピュータ記憶媒体を含むこともできる。例示するためだけに、図４は、取外し不可能な不揮発性の磁気媒体から読み出しまたはそこに書き込むハードディスクドライブ４３１、取外し可能な不揮発性の磁気ディスク４５２から読み出しまたはそこに書き込む磁気ディスクドライブ４５１、およびＣＤ−ＲＯＭ、ＣＤＲＷ、ＤＶＤまたは他の光学媒体などの取外し可能な不揮発性の光ディスク４５６から読み出しまたはそこに書き込む光ディスクドライブ４５５を示している。例示的な動作環境で使用することができる他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体には、それだけに限らないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ４４１は一般に、インターフェース４４０などの取外し不可能メモリインターフェースを介してシステムバス４２１に接続され、磁気ディスクドライブ４５１および光ディスクドライブ４５５は一般に、インターフェース４５０などの取外し可能メモリインターフェースによってシステムバス４２１に接続される。

上記に説明され、図４に示されたドライブおよびその関連するコンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造体、プログラムモジュールおよびコンピュータシステム４１０のための他のデータの記憶域を提供する。図４では、たとえば、ハードディスクドライブ４４１は、オペレーティングシステム４４４、アプリケーションプログラム４４５、他のプログラムモジュール４４６およびプログラムデータ４４７を格納するように示されている。これらの構成要素は、オペレーティングシステム４４４、アプリケーションプログラム４４５、他のプログラムモジュール４４６およびプログラムデータ４４７と同じであっても、それとは異なっていてもよいことに留意されたい。オペレーティングシステム４４４、アプリケーションプログラム４４５、他のプログラムモジュール４４６およびプログラムデータ４４７は、少なくともそれらがそれぞれ異なるコピーであることを示すために、ここでは異なる番号が付けられている。

ユーザは、キーボード４６２、および一般にマウス、トラックボールまたはタッチパッドと呼ばれるポインティング装置４６１などの入力装置を介して、コンピュータシステム４１０にコマンドおよび情報を入力してもよい。他の入力装置（図示せず）は、マイクロホン、ジョイスティック、ゲームパッド、衛星放送アンテナ、スキャナなどを含み得る。これらおよび他の入力装置はしばしば、システムバス４２１に結合されたユーザ入力インターフェース４６０を介して処理装置４２０に接続されるが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ：ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）などの他のインターフェースおよびバス構造によって接続されてもよい。モニタ４９１、または他のタイプの表示装置もまた、ビデオインターフェース４９０などのインターフェースを介してシステムバス４２１に接続され、このビデオインターフェース４９０は、ビデオメモリ（図示せず）と通信してもよい。モニタ４９１に加えて、コンピュータシステムは、出力周辺インターフェース４９５を介して接続されてもよいスピーカ４９７およびプリンタ４９６など、他の周辺出力装置を含むこともできる。

コンピュータシステム４１０は、リモートコンピュータ４８０など、１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化または分散された環境内で動作してもよい。リモートコンピュータ４８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、また図４にはメモリ記憶装置４８１だけが示されているが、コンピュータ４１０に関して上記で説明した要素の多くまたはすべてを一般に含む。図４に示された論理接続は、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）４７１と広域ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）４７３とを含むが、他のネットワーク／バスを含むこともできる。こうしたネットワーキング環境は、家庭、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットでは一般的である。

ＬＡＮネットワーキング環境内で使用される場合は、コンピュータシステム４１０は、ネットワークインターフェースまたはアダプタ４７０を介してＬＡＮ ４７１に接続される。ＷＡＮネットワーキング環境内で使用される場合は、コンピュータシステム４１０は一般に、モデム４７２、またはインターネットなどのＷＡＮ ４７３を介して通信を確立する他の手段を含む。内部にあっても、外部にあってもよいモデム４７２は、ユーザ入力インターフェース４６０または他の適切な機構を介してシステムバス４２１に接続されてもよい。ネットワーク化された環境では、コンピュータシステム４１０に関して示されたプログラムモジュール、またはその一部は、リモートメモリ記憶装置内に格納されてもよい。限定のためではなく、例示するために、図４は、メモリ装置４８１内に常駐するリモートアプリケーションプログラム４８５を示している。示されたネットワーク接続は例示的であり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことが理解されよう。

パーソナルコンピューティングおよびインターネットの収束に鑑みて、様々な分散コンピューティングフレームワークが開発され、また開発されている。個人およびビジネスユーザは同様に、アプリケーションおよびコンピュータ装置用のシームレスに相互運用可能なウェブ対応インターフェースが提供され、コンピコンピューティング活動がますますウェブブラウザまたはネットワーク指向になっている。

たとえば、本件特許出願人から入手可能なＭＩＣＲＯＳＯＦＴ（登録商標）の．ＮＥＴ（商標）プラットフォームは、サーバ、ウェブベースのデータストレージなどのビルディングブロックサービス、およびダウンロード可能なデバイスソフトウェアを含む。本明細書では例示的な実施形態についてコンピューティング装置上に常駐するソフトウェアに関連して説明しているが、本発明の一実施形態の１つまたは複数の部分は、オペレーティングシステム、アプリケーションプログラミングインターフェース（ＡＰＩ）、あるいはコプロセッサ、表示装置および要求側オブジェクトのいずれかの間の「仲介」オブジェクトを介して、その操作が．ＮＥＴ（商標）の言語およびサービスのすべてによって実施され、その中でサポートされ、あるいはそれを介してアクセスされ、また他の分散コンピュータフレームワークにおいても同様であるように実装することもできる。

上記で言及したように、本発明の例示的な実施形態について様々なコンピューティング装置およびネットワークアーキテクチャに関連して説明したが、基礎となる概念は、ＡＰＩ性能プロファイルを収集し報告するための方法を実施することが望ましいどんなコンピューティング装置またはシステムにも適用することができる。したがって、本発明の実施形態に関連して説明された諸方法およびシステムは、様々なアプリケーションおよび装置に適用することができる。本明細書では例示的なプログラミング言語、名前および実施例が、様々な選択肢を表す典型物として選ばれているが、これらの言語、名前および実施例は、限定的であることは意図されていない。本発明の実施形態によって達成される同じ、類似のまたは等価のシステムおよび方法を達成するオブジェクトコードを提供する多数のやり方があることが当業者には理解されよう。

本明細書で説明された様々な技術は、ハードウェアまたはソフトウェアに関連して、あるいは適切な場合には両方の組合せで実装することができる。したがって、本発明の方法および装置、または特定の態様またはその一部は、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または他の任意のマシン読取り可能記憶媒体などの有形媒体で実施されたプログラムコード（すなわち命令）の形態を取ることができ、プログラムコードがコンピュータなどのマシン内にロードされ、マシンによって実行される場合、このマシンは、本発明を実施する装置となる。

本発明の態様について様々な図の好ましい実施形態に関連して説明してきたが、本発明から逸脱することなく本発明と同じ機能を実施するために、他の類似の実施形態が使用されてもよく、あるいは説明された諸実施形態に変更または追加を加えてもよいことを理解されたい。さらに、とりわけ無線ネットワーク化された装置の数が増大し続けているので、手持ち式装置のオペレーティングシステム、およびアプリケーション固有オペレーティングシステムを含めて様々なコンピュータプラットフォームが企図されていることを強調しておく。したがって、特許請求の範囲に記載された本発明は、いずれかの単一の実施形態に限定すべきではなく、添付の特許請求の範囲による広がりおよび範囲内で解釈すべきである。

ＡＰＩプロファイラシステムの例示的なソフトウェアアーキテクチャを示すブロック図である。 本発明の態様による、ＡＰＩを測定する例示的な方法を示す例示的なフローチャートである。 本発明の態様による、分散型ＡＰＩ測定スキームの例示的な方法を示す例示的なフローチャートである。 例示的なホストコンピューティング環境を示すブロック図である。

Claims (19)

1. アプリケーションプログラミングインターフェース（ＡＰＩ）の性能を測定する方法であって、
   （ａ）測定するＡＰＩのリストを作成するステップと、
   （ｂ）前記リストから単一のターゲットアプリケーションプログラミングインターフェース（ＡＰＩ）を選択するステップと、
   （ｃ）前記ターゲットＡＰＩへの呼出しをインターセプトし、タイミングおよびメモリ割当てデータを収集するステップと、
   （ｄ）前記ターゲットＡＰＩの前記タイミングおよびメモリ割当てデータを記録するステップであって、前記記録されたデータは記憶装置内に置かれるステップと、
   （ｅ）測定された結果を併合して、前記収集されたタイミングおよびメモリ割当てデータのｌｏｇ₂を示すバケット化されたデータを含む結果テーブルにするステップと、
   （ｆ）前記リスト内の各ＡＰＩについてステップ（ｂ）からステップ（ｅ）を繰り返すステップと
   を備えることを特徴とする方法。
2. 結果のデータベースを生成し、前記データベースをＡＰＩ性能データのユーザが使用できるようにするステップをさらに備えることを特徴とする請求項１に記載の方法。
3. 各機能のヒストグラムを使用してグラフィカルユーザインターフェースを介して前記結果テーブルを提示するステップをさらに備えることを特徴とする請求項１に記載の方法。
4. 前記ターゲットＡＰＩによって呼び出された機能のリストを生成するステップであって、前記リストは、前記呼出しスタック上に決して同時に現れない機能を備える非干渉機能を備えるステップと、
   複数の非干渉機能についてのタイミングおよびメモリ割当てを同時に測定するステップと
   をさらに備えることを特徴とする請求項１に記載の方法。
5. 前記非干渉機能の測定された実行結果を併合して、前記タイミングおよびメモリ割当てデータのｌｏｇ₂を示すバケット化されたデータを含む結果テーブルにするステップをさらに備えることを特徴とする請求項４に記載の方法。
6. 各機能のヒストグラムを使用してグラフィカルユーザインターフェースを介して前記結果テーブルを提示するステップをさらに備えることを特徴とする請求項５に記載の方法。
7. ＡＰＩの性能を測定するプログラムは複数のユーザコンピュータ内に常駐し、
   記憶装置内の前記記録されたデータが閾値量を超えるかどうか確認するためにテストするステップと、
   前記閾値量を超えない場合は、メモリ割当ておよびタイミングデータを測定するユーザコンピュータ内の別のＡＰＩを選択し、ステップ（ｂ）からステップ（ｅ）を繰り返すステップと、
   記憶装置内の前記記録されたデータが前記閾値量を超える場合は、記憶装置内の前記記録されたデータを中央サービス位置に提出するステップであって、前記中央サービス位置は記憶装置内にＡＰＩ測定データを有するステップと、
   中央記憶位置で、前記提出されたデータを記憶装置内の前記ＡＰＩ測定データと集約するステップと、
   結果データベースを生成し、前記データベースをＡＰＩ性能データのユーザが使用可能とするステップとをさらに備えることを特徴とする請求項１に記載の方法。
8. メモリ割当ておよびタイミングデータを測定するＡＰＩを選択するステップは、ターゲットＡＰＩを選択するために乱数発生器を使用するステップを備えることを特徴とする請求項１に記載の方法。
9. アプリケーションプログラミングインターフェース（ＡＰＩ）の性能データを取得するためのコンピュータシステムであって、
   ソフトウェア命令を実行するプロセッサを備え、前記ソフトウェア命令は、
   ターゲットのアプリケーションプログラミングインターフェース（ＡＰＩ）のメモリ割当て測定値を生成する、前記ＡＰＩによって機能が呼び出される回数を測定し記録するメモリ割当てプロファイラモジュールと、
   前記ターゲットＡＰＩのタイミング測定値を生成する、前記ＡＰＩに関連するタイミング情報を測定し記録するタイミングプロファイラモジュールと、
   前記ターゲットＡＰＩの各呼出しごとに１回、前記メモリ割当てモジュールおよび前記タイミングプロファイラモジュールを実行し、同じ呼出しスタックに現れる２つのＡＰＩを同時に測定することを回避する調整モジュールと、
   前記ターゲットＡＰＩの前記メモリ割当て測定値と前記タイミング測定値とを組み合わせて、結果テーブルにする併合ツールモジュールと、
   前記結果テーブルのデータを、前記メモリ割当ておよびタイミング測定値のｌｏｇ₂バケット化による形で表示することができるユーザインターフェースモジュールと
   を備えることを特徴とするコンピュータシステム。
10. 前記メモリ割当てプロファイラは、包含的メモリ割当て値と排他的メモリ割当て値を別々に測定し記録することを特徴とする請求項９に記載のコンピュータシステム。
11. 前記ユーザインターフェースモジュールは、測定された各機能呼出しについて、前記結果テーブルのデータをヒストグラムの形へとレンダリングするグラフィカルユーザインターフェースをさらに備えることを特徴とする請求項９に記載のコンピュータシステム。
12. アプリケーションプログラミングインターフェース（ＡＰＩ）の性能データを取得する方法を実施するためのコンピュータ実行可能命令を含むコンピュータ読取り可能媒体であって、前記方法は、
    （ａ）測定するＡＰＩのリストを作成するステップと、
    （ｂ）前記リストから単一のターゲットＡＰＩを選択するステップと、
    （ｃ）前記ターゲットＡＰＩへの呼出しをインターセプトし、タイミングおよびメモリ割当てデータを収集するステップと、
    （ｄ）前記ターゲットＡＰＩの前記タイミングおよびメモリ割当てデータを記録するステップであって、前記記録されたデータは記憶装置内に置かれるステップと、
    （ｅ）測定された結果を併合して、前記収集されたタイミングおよびメモリ割当てデータのｌｏｇ₂を示すバケット化されたデータを含む結果テーブルにするステップと、
    （ｆ）前記リスト内の各ＡＰＩについてステップ（ｂ）からステップ（ｅ）を繰り返すステップと
    を備えることを特徴とするコンピュータ読取り可能媒体。
13. 結果のデータベースを生成し、前記データベースをＡＰＩ性能データのユーザが使用できるようにするステップをさらに備えることを特徴とする請求項１２に記載のコンピュータ読取り可能媒体。
14. 各機能のヒストグラムを使用してグラフィカルユーザインターフェースを介して前記結果テーブルを提示するステップをさらに備えることを特徴とする請求項１２に記載のコンピュータ読取り可能媒体。
15. 前記ターゲットＡＰＩによって呼び出された機能のリストを生成するステップであって、前記リストは、前記呼出しスタック上に決して同時に現れない機能を備える非干渉機能を備えるステップと、
    複数の非干渉機能についてのタイミングおよびメモリ割当てを同時に測定するステップと
    をさらに備えることを特徴とする請求項１２に記載のコンピュータ読取り可能媒体。
16. 前記非干渉機能の測定された実行結果を併合して、前記タイミングおよびメモリ割当てデータのｌｏｇ₂を示すバケット化されたデータを含む結果テーブルにするステップをさらに備えることを特徴とする請求項１５に記載のコンピュータ読取り可能媒体。
17. 各機能のヒストグラムを使用してグラフィカルユーザインターフェースを介して前記結果テーブルを提示するステップをさらに備えることを特徴とする請求項１６に記載のコンピュータ読取り可能媒体。
18. 記憶装置内の前記記録されたデータが閾値量を超えるかどうか確認するためにテストするステップと、
    前記閾値量を超えない場合は、メモリ割当ておよびタイミングデータを測定する別のＡＰＩを選択し、ステップ（ｂ）からステップ（ｅ）を繰り返すステップと、
    記憶装置内の前記記録されたデータが前記閾値量を超える場合は、記憶装置内の前記記録されたデータを中央サービス位置に提出するステップであって、前記中央サービス位置は記憶装置内のＡＰＩ測定データを有する、ステップと、
    中央記憶位置で、前記提出されたデータを記憶装置内の前記ＡＰＩ測定データと集約するステップと、
    結果データベースを生成し、前記データベースをＡＰＩ性能データのユーザが使用可能とするステップと
    をさらに備えることを特徴とする請求項１２に記載のコンピュータ読取り可能媒体。
19. メモリ割当ておよびタイミングデータを測定するＡＰＩを選択するステップは、ターゲットＡＰＩを選択するために乱数発生器を使用するステップを備えることを特徴とする請求項１２に記載のコンピュータ読取り可能媒体。

Images