▶ グリーン ヒルズ ソフトウェア，インコーポレイテッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-08-23
(45)【発行日】2023-08-31
(54)【発明の名称】トレースデータの要約及び視覚化のためのシステム及び方法
(51)【国際特許分類】
G06F 11/32 20060101AFI20230824BHJP
G06F 11/34 20060101ALI20230824BHJP
【ＦＩ】
G06F11/32 130
G06F11/34 166
【請求項の数】
13
【外国語出願】
(21)【出願番号】P 2022002370
(22)【出願日】2022-01-11
(62)【分割の表示】P 2021118678の分割
【原出願日】2017-10-10
(65)【公開番号】P2022043324
(43)【公開日】2022-03-15
【審査請求日】2022-01-17
(31)【優先権主張番号】62/406,518
(32)【優先日】2016-10-11
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】519114672
【氏名又は名称】グリーン ヒルズ ソフトウェア，インコーポレイテッド
(74)【代理人】
【識別番号】100079108
【弁理士】
【氏名又は名称】稲葉 良幸
(74)【代理人】
【識別番号】100109346
【弁理士】
【氏名又は名称】大貫 敏史
(74)【代理人】
【識別番号】100117189
【弁理士】
【氏名又は名称】江口 昭彦
(74)【代理人】
【識別番号】100134120
【弁理士】
【氏名又は名称】内藤 和彦
(72)【発明者】
【氏名】オダウド，ダニエル，ディー．
(72)【発明者】
【氏名】フィールド，ネイサン，ディー．
(72)【発明者】
【氏名】ムリニックス，エヴァン，ディー．
(72)【発明者】
【氏名】テヴィス，グウェン，イー．
(72)【発明者】
【氏名】ヴァレルジェフ，ニコラ
(72)【発明者】
【氏名】カッシング，ケヴィン，エル．
(72)【発明者】
【氏名】グリーン，マロリー，エム．，セカンド．
(72)【発明者】
【氏名】エディントン，グレゴリー，エヌ．
(72)【発明者】
【氏名】ザヴィスカ，トム，アール．
【審査官】岩田 玲彦
(56)【参考文献】
【文献】特開２０１２－２４８１１８（ＪＰ，Ａ）
【文献】特開２０１０－１０８２２１（ＪＰ，Ａ）
【文献】特開２０１１－１７０７４９（ＪＰ，Ａ）
【文献】特開２０００－２５０７８０（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１１／０１３１５５２（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １１／３２
Ｇ０６Ｆ １１／３４
(57)【特許請求の範囲】
【請求項1】
呼出しスタックグラフ内のスレッドの実行履歴の視覚化を表示するためのコンピュータ実装方法であって、複数の関数呼出しが、表示装置での１ピクセル実行単位により表される時間範囲の所与の呼出しスタックレベルの中で発生するとき、コンピュータ化されたレンダリングエンジンによって前記複数の関数呼出しを処理して、第１の色を前記ピクセル実行単位に割り当て、前記第１の色が前記複数の関数呼出しと関連付けられ、前記方法は、複数の前記スレッドの複数の呼出しスタックグラフを表示することをさらに含み、前記呼出しスタックグラフが、そのそれぞれの時間軸のそれぞれに沿って同期する、方法。
【請求項2】
複数のレベルを含む呼出しスタックを表すトレースイベントストリームを要約するためのコンピュータ実装方法であって、コンピュータ化された要約エンジンによって、前記呼出しスタックの各レベルがトレースイベントの対応するストリームに割り当てられ、前記コンピュータ化された要約エンジンによって、各呼出しスタックレベルあたりのトレースイベントストリームが要約され、コンピュータ化されたレンダリングエンジンによって、前記要約された呼出しスタックレベルあたりのトレースイベントストリームのそれぞれが、表示装置上の対応する呼出しスタック深さの相対位置で前記表示装置にレンダリングされる、方法。
【請求項3】
複数のレベルを含む呼出しスタックを表すトレースイベントストリームを表示するためのコンピュータ実装方法であって、コンピュータ化された要約エンジンによって、前記呼出しスタックの各レベルがトレースイベントの対応するストリームに割り当てられ、前記コンピュータ化された要約エンジンによって、各呼出しスタックレベルあたりのトレースイベントストリームが要約され、これによりピクセル実行単位あたり２つ以上の呼出し又は戻りがあり、コンピュータ化されたレンダリングエンジンによって、前記要約された呼出しスタックレベルのそれぞれが、表示装置上のその呼出しスタック深さの相対位置で前記表示装置にレンダリングされ、前記方法は、複数のスレッドの複数の呼出しスタックグラフを表示することをさらに含み、前記呼出しスタックグラフが、そのそれぞれの時間軸のそれぞれに沿って同期する、方法。
【請求項4】
複数のレベルを含む呼出しスタックを表すトレースイベントストリームを表示するためのコンピュータ実装方法であって、コンピュータ化された要約エンジンによって、前記呼出しスタックの各レベルがトレースイベントの対応するストリームに割り当てられ、前記コンピュータ化された要約エンジンによって、各呼出しスタックレベルあたりのトレースイベントストリームが要約され、これによりピクセル実行単位あたり複数の呼出し又は戻りがあるとき、コンピュータ化されたレンダリングエンジンによって、前記ピクセル実行単位の情報に含まれる前記複数の呼出し又は戻りについてなんらかの区別情報が示され、前記コンピュータ化されたレンダリングエンジンによって、前記要約された呼出しスタックレベルのそれぞれが、表示装置上のその呼出しスタック深さの相対位置で前記表示装置にレンダリングされ、前記方法は、複数のスレッドの複数の呼出しスタックグラフを表示することをさらに含み、前記呼出しスタックグラフが、そのそれぞれの時間軸のそれぞれに沿って同期する、方法。
【請求項5】
複数の切れ目及び複数のレベルを備える呼出しスタックを表すトレースイベントストリームを要約するためのコンピュータ実装方法であって、コンピュータ化された要約エンジンによって、前記呼出しスタックの前記レベルのそれぞれが、トレースイベントの専用のストリームに割り当てられ、
前記コンピュータ化された要約エンジンによって、呼出しスタックレベルあたりの各トレースイベントストリームが要約され、
前記コンピュータ化された要約エンジンによって、コンピュータシステムの実行による前記トレースイベントストリームの生成が、どれほど多くのレベルが加えられる、及び／又は前記切れ目で削除されるのかを再構築するために必要な情報を含むために修正され、
レンダリングエンジンが、複数の異なる呼出しスタック要約を単一のコヒーレントビューにつなぎ合わせるために修正され、前記複数の異なる呼出しスタック要約が表示装置に連続して表示され、
前記コンピュータ化された要約エンジンによって前記切れ目での深さが決定されるとき、次いで、前記コンピュータ化された要約エンジンによって、新規に要約されたデータが、前記呼出しスタックレベルあたりの要約されたデータとマージされる、方法。
【請求項6】
複数の切れ目及び複数のレベルを備える呼出しスタックを表すトレースイベントストリームを要約するためのコンピュータ実装方法であって、コンピュータ化された要約エンジンによって、前記呼出しスタックの前記レベルのそれぞれが、トレースイベントの専用のストリームに割り当てられ、
前記コンピュータ化された要約エンジンによって、呼出しスタックレベルあたりの各トレースイベントストリームが要約され、
前記コンピュータ化された要約エンジンによって、加えられる、及び／又は削除される呼出しスタックレベルの数が、コード実行の所与の点について静的に決定され、
レンダリングエンジンが、複数の異なる呼出しスタック要約を単一のコヒーレントビューにつなぎ合わせるために修正され、前記複数の異なる呼出しスタック要約が表示装置に連続して表示され、
前記コンピュータ化された要約エンジンによって前記切れ目での深さが決定されるとき、次いで、前記コンピュータ化された要約エンジンによって、新規に要約されたデータが、前記呼出しスタックレベルあたりの要約されたデータとマージされる、方法。
【請求項7】
複数の切れ目及び複数のレベルを備える呼出しスタックを表すトレースイベントストリームを要約するためのコンピュータ実装方法であって、コンピュータ化された要約エンジンによって、前記呼出しスタックの前記レベルのそれぞれが、トレースイベントの専用のストリームに割り当てられ、
前記コンピュータ化された要約エンジンによって、呼出しスタックレベルあたりの各トレースイベントストリームが要約され、
前記コンピュータ化された要約エンジンによって、前記トレースイベントのストリームが、前記呼出しスタック深さを明確に決定することが可能になるまで切れ目の点から走査され、
レンダリングエンジンが、複数の異なる呼出しスタック要約を単一のコヒーレントビューにつなぎ合わせるために修正され、前記複数の異なる呼出しスタック要約が表示装置に連続して表示され、
前記コンピュータ化された要約エンジンによって前記切れ目での深さが決定されるとき、次いで、前記コンピュータ化された要約エンジンによって、新規に要約されたデータが、前記呼出しスタックレベルあたりの要約されたデータとマージされる、方法。
【請求項8】
前記走査の後、前記トレースイベントのストリームの中の前記トレースイベントを呼出しスタックレベルに割り振ることをさらに含む、請求項７に記載の方法。
【請求項9】
前記コンピュータシステムの実行による前記トレースイベントストリームの前記生成が、現在の呼出しスタック深さについての周期的な表記を含むために修正される、請求項５に記載の方法。
【請求項10】
複数の切れ目及び複数のレベルを備える呼出しスタックを表すトレースイベントストリームを要約するためのコンピュータ実装方法であって、コンピュータ化された要約エンジンによって、前記呼出しスタックの前記レベルのそれぞれが、トレースイベントの専用のストリームに割り当てられ、
前記コンピュータ化された要約エンジンによって、呼出しスタックレベルあたりの各トレースイベントストリームが要約され、
前記コンピュータ化された要約エンジンによって、前記呼出しスタックの前記要約が切れ目の点で終了し、
レンダリングエンジンが、複数の異なる呼出しスタック要約を単一のコヒーレントビューにつなぎ合わせるために修正され、前記複数の異なる呼出しスタック要約が表示装置に連続して表示され、
前記コンピュータ化された要約エンジンによって前記切れ目での深さが決定されるとき、次いで、前記コンピュータ化された要約エンジンによって、新規に要約されたデータが、前記呼出しスタックレベルあたりの要約されたデータとマージされる、方法。
【請求項11】
複数の切れ目及び複数のレベルを備える呼出しスタックを表すトレースイベントストリームを要約するためのコンピュータ実装方法であって、コンピュータ化された要約エンジンによって、前記呼出しスタックの前記レベルのそれぞれが、トレースイベントの専用のストリームに割り当てられ、
前記コンピュータ化された要約エンジンによって、呼出しスタックレベルあたりの各トレースイベントストリームが要約され、
前記コンピュータ化された要約エンジンによって、前記呼出しスタックの前記要約が、切れ目の点で終了し、
前記コンピュータ化された要約エンジンによって、新しい呼出しスタック要約ストリームが始まり、
レンダリングエンジンが、複数の異なる呼出しスタック要約を単一のコヒーレントビューにつなぎ合わせるために修正され、前記複数の異なる呼出しスタック要約が表示装置に連続して表示され、
前記コンピュータ化された要約エンジンによって前記切れ目での深さが決定されるとき、次いで、前記コンピュータ化された要約エンジンによって、新規に要約されたデータが、前記呼出しスタックレベルあたりの要約されたデータとマージされる、方法。
【請求項12】
複数の切れ目及び複数のレベルを備える呼出しスタックを表すトレースイベントストリームを要約するためのコンピュータ実装方法であって、コンピュータ化された要約エンジンによって、前記呼出しスタックの前記レベルのそれぞれが、トレースイベントの専用のストリームに割り当てられ、
前記コンピュータ化された要約エンジンによって、呼出しスタックレベルあたりの各トレースイベントストリームが要約され、
前記コンピュータ化された要約エンジンによって、前記呼出しスタックの前記要約が、切れ目に遭遇すると一時停止され、前記コンピュータ化された要約エンジンによって、一時的な新しい要約が前記切れ目で始まり、
前記コンピュータ化された要約エンジンによって前記切れ目点での深さが決定されるとき、次いで、前記コンピュータ化された要約エンジンによって、新規に要約されたデータが、前記一時停止された呼出しスタックレベルあたりの要約されたデータとマージされ、次いで、前記コンピュータ化された要約エンジンによって、前記呼出しスタックの前記要約が一時停止を解除され、
レンダリングエンジンが、元の要約されたデータとつなぎ合わされた前記一時的な新しい要約されたデータを単一のコヒーレントビューに表示する、方法。
【請求項13】
複数のレベルを備える呼出しスタックを表すトレースイベントストリームを表示するための装置であって、コンピュータ化された要約エンジンによって、前記呼出しスタックの各レベルが、トレースイベントの対応するストリームに割り当てられ、前記コンピュータ化された要約エンジンによって、呼出しスタックレベルあたりの各トレースイベントストリームが要約され、これによりピクセル実行単位あたり２つ以上の呼出し又は戻りがあるとき、複数の呼出しがあるという事実を超えて、前記ピクセル実行単位の情報に含まれる前記複数の呼出し又は戻りについてなんらかの区別情報が示され、コンピュータ化されたレンダリングエンジンによって、前記要約された呼出しスタックレベルのそれぞれが、表示装置上のその呼出しスタック深さの相対位置で前記表示装置にレンダリングされ、前記装置は、複数のスレッドの複数の呼出しスタックグラフをさらに含み、前記呼出しスタックグラフが、そのそれぞれの時間軸のそれぞれに沿って同期する、装置。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
[0001] 本願は、米国特許法第１１９条の下で、すべての目的のために参照により本明細書に援用される、「Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｓｕｍｍａｒｉｚａｔｉｏｎ ａｎｄ Ｖｉｓｕａｌｉｚａｔｉｏｎ ｏｆ Ｔｒａｃｅ Ｄａｔａ」と題する２０１６年１０月１１日に出願された米国仮特許出願第６２／４０６，５１８号（代理人整理番号第ＧＨＳ－０１００－Ｐ号）の優先権を主張する。
[0001] 本願は、米国特許法第１１９条の下で、すべての目的のために参照により本明細書に援用される、「Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｓｕｍｍａｒｉｚａｔｉｏｎ ａｎｄ Ｖｉｓｕａｌｉｚａｔｉｏｎ ｏｆ Ｔｒａｃｅ Ｄａｔａ」と題する２０１６年１０月１１日に出願された米国仮特許出願第６２／４０６，５１８号（代理人整理番号第ＧＨＳ－０１００－Ｐ号）の優先権を主張する。
【背景技術】
【0002】
[0002]１．開示の分野
[0003] 本開示は、概して、１つ以上のコンピュータシステムの実行中に収集されるトレースデータ又はログデータを視覚化及び／又は分析するためのシステム及び方法に関し、より詳細には、そうした視覚化及び／又は分析を容易にするためにユーザインタフェース、データ要約技術、及び／又は基本的なファイル構造を提供することに関する。
[0003] 本開示は、概して、１つ以上のコンピュータシステムの実行中に収集されるトレースデータ又はログデータを視覚化及び／又は分析するためのシステム及び方法に関し、より詳細には、そうした視覚化及び／又は分析を容易にするためにユーザインタフェース、データ要約技術、及び／又は基本的なファイル構造を提供することに関する。
【0003】
[0004]２．一般的背景
[0005] 当該技術分野で既知のいくつかのデバッグ解決策は、ハードウェア、ファームウェア、及びソフトウェアの開発者が、バグ及び／又はエラーを発見し、修正し、そのコードを最適化及び／又は試験できるようにするさまざまな分析ツールを提供する。これらの分析ツールの１つのクラスは、多種多様のソースから生成できるログデータを考察する。概して、このログデータは、１つ以上のプロセッサ上で命令を実行している間に生成される。ログデータは、プロセッサ自体（例えば、プロセッサトレース）によって、オペレーティングシステムによって、ソフトウェア開発者により加えられる計装ログポイント、コンパイラによって加えられる計装、（例えばコード生成ジェネレータ等の）自動システムにより加えられる計装によって、又はコンピュータシステム内の任意の他の機構によって生成できる。論理アナライザ、システムの集合体、及びバリデーションスクリプト、試験インフラストラクチャ、物理センサ、又は他のソースからのログ等のログデータの他のソースは、システムにとって外部である場合がある。これらの異なるソースの任意の組合せにより生成されるデータは、本書を通して「トレースデータ」（及び／又は「トレースイベントのストリーム」）と呼ばれる。トレースデータの単一の要素は、「トレースイベント」又は単に「イベント」と呼ばれる。トレースイベントの「ストリーム」は、その用語がここで使用されるように、時間（前方に又は後方にのどちらか）又は他の実行の単位別に並べ替えられてよい複数のトレースイベントのシーケンスを指す。トレースイベントのストリームはサブストリームに分類又は割り当てられてよく、トレースイベントの部分集合はサブストリームの中に収集され、サブストリームを含む。従って、サブストリームも、トレースイベントのストリームと見なされる場合がある。トレースイベントは、多種多様な種類のデータを表す場合がある。例えば制限なく実行サイクル数、キャッシュミス数、移動距離等の実行単位の他の表現も考えられるが、一般的に言えば、トレースイベントはタイムスタンプを有する。また、トレースイベントは、概してデータの要素も含む。制限なく、トレースデータが表すデータの種類の例は、整数又は浮動小数点値、文字列、特定の関数が入れられた又は出た旨の表示（「関数入口／出口情報」）、アドレス値、スレッドステータス（実行中、ブロックされている等）、ヒープ上で割り振られた／解放されたメモリ、アドレスでの値、電力活用、電圧、移動距離、経過時間等を含む。
[0005] 当該技術分野で既知のいくつかのデバッグ解決策は、ハードウェア、ファームウェア、及びソフトウェアの開発者が、バグ及び／又はエラーを発見し、修正し、そのコードを最適化及び／又は試験できるようにするさまざまな分析ツールを提供する。これらの分析ツールの１つのクラスは、多種多様のソースから生成できるログデータを考察する。概して、このログデータは、１つ以上のプロセッサ上で命令を実行している間に生成される。ログデータは、プロセッサ自体（例えば、プロセッサトレース）によって、オペレーティングシステムによって、ソフトウェア開発者により加えられる計装ログポイント、コンパイラによって加えられる計装、（例えばコード生成ジェネレータ等の）自動システムにより加えられる計装によって、又はコンピュータシステム内の任意の他の機構によって生成できる。論理アナライザ、システムの集合体、及びバリデーションスクリプト、試験インフラストラクチャ、物理センサ、又は他のソースからのログ等のログデータの他のソースは、システムにとって外部である場合がある。これらの異なるソースの任意の組合せにより生成されるデータは、本書を通して「トレースデータ」（及び／又は「トレースイベントのストリーム」）と呼ばれる。トレースデータの単一の要素は、「トレースイベント」又は単に「イベント」と呼ばれる。トレースイベントの「ストリーム」は、その用語がここで使用されるように、時間（前方に又は後方にのどちらか）又は他の実行の単位別に並べ替えられてよい複数のトレースイベントのシーケンスを指す。トレースイベントのストリームはサブストリームに分類又は割り当てられてよく、トレースイベントの部分集合はサブストリームの中に収集され、サブストリームを含む。従って、サブストリームも、トレースイベントのストリームと見なされる場合がある。トレースイベントは、多種多様な種類のデータを表す場合がある。例えば制限なく実行サイクル数、キャッシュミス数、移動距離等の実行単位の他の表現も考えられるが、一般的に言えば、トレースイベントはタイムスタンプを有する。また、トレースイベントは、概してデータの要素も含む。制限なく、トレースデータが表すデータの種類の例は、整数又は浮動小数点値、文字列、特定の関数が入れられた又は出た旨の表示（「関数入口／出口情報」）、アドレス値、スレッドステータス（実行中、ブロックされている等）、ヒープ上で割り振られた／解放されたメモリ、アドレスでの値、電力活用、電圧、移動距離、経過時間等を含む。
【発明の概要】
【0004】
[0006] 本明細書に使用されるように、用語「コンピュータシステム」は、ＲＡＭ、ＲＯＭ、内蔵ＳＲＡＭ、オンチップＲＡＭ、オンチップフラッシュ、ＣＤ－ＲＯＭ、ハードディスク等を含むが、これに限定されるものではない処理ユニットとデータ及び命令を交換するための１つ以上のデータストレージデバイスと結合される、データ及び命令を処理するための（例えば、中央処理装置、ＣＰＵ等の）１つ以上の処理装置を含むと定義される。コンピュータシステムの例は、エンジンコントローラからラップトップコンピュータ又はデスクトップコンピュータ、スーパーコンピュータまでのすべてを含む。データストレージデバイスは、専用、つまり処理ユニットと直接的に結合される、又は遠隔、つまりコンピュータネットワーク上で処理ユニットと結合される場合がある。コンピュータネットワークを介して処理ユニットと結合される遠隔データストレージデバイスは、実行のために処理ユニットにプログラム命令を送信できる場合があることが理解されるべきである。さらに、処理装置は、同じ物理構造（例えば、パラレルプロセッサ）を通して又はコンピュータネットワーク（例えば、分散プロセッサ）を介してのどちらかで１つ以上の追加の処理装置と結合できる。そうした遠隔で結合されたデータストレージデバイス及びプロセッサの使用は、コンピュータサイエンス技術の当業者によく知られるであろう。本明細書で使用される用語「コンピュータネットワーク」は、互いと通信できるコンピュータシステムの集合を相互接続する通信チャネルの集合を含むと定義される。通信チャネルは、例えばツイストペアワイヤ、同軸ケーブル、光ファイバ、衛星リンク、又はデジタルマイクロ波無線等を含むが、これに限定されるものではない伝送媒体を含む場合がある。コンピュータシステムは、大規模な、つまり「広」域（例えば、数十マイル、数百マイル、若しくは数千マイルを介して、ＷＡＮ）、又はローカルエリアネットワーク（例えば、数フィートから数百フィートを介して、ＬＡＮ）で分散される場合がある。さらに、さまざまなローカルエリアネットワーク及び広域ネットワークは、コンピュータシステムの集合ネットワークを形成するために結合できる。コンピュータネットワークのそうした連合の一例が、「インターネット」である。
【0005】
[0007] 本明細書で使用されるように、用語「ターゲット」は、「コンピュータシステム」と同義である。用語ターゲットは、トレースイベントを生成するコンピュータシステムが、トレースイベントを分析するために使用されるコンピュータシステムとは異なる場合があることを示すために使用される。同じコンピュータシステムが、トレースイベントの生成と分析の両方を行うことができることに留意されたい。
【0006】
[0008] 本明細書で使用されるように、用語「スレッド」は、命令を実行する任意の演算器を指すために使用される。スレッドは、通常、おもにそれ専用である（例えば、レジスタ等の）状態を記憶する方法を有する。スレッドは、追加状態記憶領域を（例えば、そのアドレス空間内のＲＡＭ等の）他のスレッドと共用する場合もあれば、共用しない場合もある。例えば、これは、オペレーティングシステム内で実行されるとき、プロセスの内側で実行しているスレッドを指す場合がある。また、この定義は、オペレーティングシステムのないプロセッサ上で命令を実行することも含む。その場合、「スレッド」は、プロセッサ実行命令であり、コンテクストスイッチはない。異なるオペレーティングシステム及び環境は、用語スレッドでカバーされる概念を指すために異なる用語を使用してよい。同じ基本的な原理の他の共通用語は、ハードウェアスレッド、軽量プロセス、ユーザースレッド、グリーンスレッド、カーネルスレッド、タスク、プロセス、及びファイバを制限なく含む。
【0007】
[0009] ソフトウェア開発者が、バグ、性能問題、及び試験の難しさを生じさせる場合がある、ソフトウェア内でのしばしば複雑なインタラクションをよりうまく理解できるようにする改善されたトレースデータ視覚化ツール及び／又は分析ツールの必要性が存在する。また、ソフトウェア開発者がトレースデータの潜在的に大きい集合体の中を迅速にナビゲートできるように、理解しやすいディスプレイ及びインタフェースで関連性のあるトレースデータ情報をユーザに提示するシステム及び方法の必要性も存在する。
【0008】
[0010] 複雑な及び／又は大きいソフトウェアプロジェクトがどのようにして機能するのか、並びにそのさまざまな構成要素が互いと、及びその操作環境とどのようにしてインタラクションするのかを理解することは、難しいタスクである。これは、部分的には、コードの任意の行が潜在的にシステムの任意の他の部分に影響を与える場合があるためである。そうした環境では、通常、数十万行を超える長さのプログラムのあらゆる行を理解できる人はいない。
【0009】
[0011] 現実問題としては、複雑な及び／又は大きいソフトウェアプログラムは、プログラムの開発者がプログラムがどのようにして機能するのかを考えるのとは大幅に異なって動く場合がある。多くの場合、少数の開発者が、システムの大部分が高いレベルでどのようにして機能するのかを理解し、多数の開発者は、自分たちが頻繁に作業するシステムの相対的に小さい部分を理解している。
【0010】
[0012] この苛立たしいが、多くの場合避けることができないソフトウェアシステム開発の態様は、予想外且つデバッグが困難な故障、不十分なシステム性能、及び／又は低い開発者生産性につながる場合がある。
【0011】
[0013] 従って、開発者の理解及びそうした大きい／複雑なプログラムの動きの分析を容易にし、開発者がそうしたプログラムの動作の態様を視覚化できるようにする方法及びシステムを提供することが望ましい。
【0012】
[0014] 典型的な大きいソフトウェアプログラムが動作するとき、数十億のトレースイベントが毎秒発生する場合がある。さらに、いくつかの興味深い動きは、それら自体を明示する又は明らかにするためにきわめて長い時間（秒で測定されるのか、日で測定されるのか、又は年で測定されるのかにも関わらず）を要する場合がある。
【0013】
[0015] この環境での課題は、任意の数のプロセッサを有するシステムから生成され、数日から数年の実行時間に及ぶ場合がある数十億のトレースイベントの表示を潜在的に処理できるツールを提供することである。表示はユーザを圧倒してはならず、しかも表示は、全体的なシステムの有用な高いレベルのビューと、数ピコ秒おきに発生する場合がある個々のイベントの検査を可能にする低レベルのビューの両方を提供しなくてはならない。これらの機能性のすべては、開発者が共通のデスクトップコンピュータを使用し、利用可能でなければならず、そうした開発者の要求から数秒以内に実現されなければならない。そうしたツールは、特にシステムのデバッグ、性能調整、理解、及び試験においてソフトウェア開発者を非常に効率的にすることができる。
【0014】
[0016] コンピュータプログラムがどのように実行中であるのかを視覚化し、分析するためのさまざまなシステム、方法、及び技術が、当業者にとって既知である。
【0015】
[0017] 例えば、ＰＡＴＨＡＮＡＬＹＺＥＲ（商標）（Ｇｒｅｅｎ Ｈｉｌｌｓ Ｓｏｆｔｗａｒｅ， Ｉｎｃ．から市販されているツール）は、ソフトウェアアプリケーションの呼出しスタックのビューを継時的に表示するためにカラーパターンを使用し、ＰＡＴＨＡＮＡＬＹＺＥＲ（商標）は、開発者が、アプリケーションが予想される実行経路からどこで逸れるのかを識別するのを支援する。ＰＡＴＨＡＮＡＬＹＺＥＲ（商標）は、ユーザが（選択された領域の幅が、データの特定の期間を表す）その表示の選択した領域を拡大する又はズームインすることを可能にする。さらに、ＰＡＴＨＡＮＡＬＹＺＥＲ（商標）は、ユーザが拡大された表示上で左右に移動又はパンして、現在の表示の選択期間外である場合がある前のデータ及びより後のデータを示すことができるようにする。しかしながら、このツールから利用可能である呼出しスタックビューは、システム内の全スレッドに関し、ツールはスレッドを別個の表示に分けない。従って、それを使用している開発者が、自分にとって最も興味深いスレッドの部分集合を追跡することは困難である。さらに、ＰＡＴＨＡＮＡＬＹＺＥＲ（商標）は、システム内の異なるプロセッサ間で切り替わる単一のスレッドに視覚化を提供していない。
【0016】
[0018] さらに、ＰＡＴＨＡＮＡＬＹＺＥＲ（商標）ツールの視覚化機能は、通常、それが時間の大きい範囲及び多数のスレッドに対応しているとき低下する。例えば、システム負荷は表されず、複数の呼出しが単一のピクセル実行単位の中で発生する領域はグレーに印影が付けられる。結果として、開発者が時間の大きい範囲を分析することは困難である。また、このツールのレンダリング性能は、（例えばハードディスクドライブ等の）コンピュータ可読媒体に記憶された分析済みのデータを通して多数のシークを実行するその必要性によっても制限される。これにより、ツールは、約１ギガバイトよりも大きいデータセットを見るには実用的ではなくなる。最後に、ユーザが収集されたデータを検査するのを手助けする、又は表示されるものを目の前の作業に関連性のあるデータだけに制限するための限られた機能がある。
【0017】
[0019] プログラムのデバッグ／視覚化のための当業者に既知の他のツールは、いわゆる「フレームグラフ（ｆｌａｍｅ ｇｒａｐｈ）」を含む。フレームグラフは、上述されたＰＡＴＨＡＮＡＬＹＺＥＲ（商標）ツールのビューに類似しているようにみえる呼出しスタックビューを提供してよいが、フレームグラフでは、プログラムの呼出しスタックを通る各経路の時間が合計され、経路の総時間だけが表示される。結果として、関数呼出しの異常に長い又は短い実行時間の観点からスレッド間の外れ値又はインタラクションを見る優れた方法はない。さらに、大部分の情報はその分析中に削除されるため、フレームグラフは、非常に小さいデータセットに作用する。さらに、フレームグラフは相対的に劣った視覚化方法を提供する。例えば、フレームグラフは十分なズーミング／パニングビューを提供せず、（１）オペレーティングシステム（ＯＳ）レベルでのイベント、（２）コンピュータシステムによって内部で生成されるイベント、（３）スレッド間のインタラクション、又は（４）コンピュータシステムの外部で生成されるイベントとの統合はない。
【0018】
[0020] 従って、当該技術分野で限界に対処することが望ましい。具体的には、本明細書に説明されるように、本発明の態様は、コンピュータ化されたデータの要約、操作、及び視覚化の技術の応用によりコンピュータ技術の分野で発生する問題に対処する。
【0019】
[0021] 例として、ここで原寸に比例していない添付図面に対して参照が行われる。
【図面の簡単な説明】
【0020】
【図1】[0022]本発明の特定の実施形態の態様を示す例示的なハイレベル図である。
【図2】[0023]本発明の特定の実施形態に係るトレースデータ視覚化の態様を実装するユーザインタフェースを示す図である。
【図3】[0024]本発明の特定の実施形態に係るトレースデータ視覚化に関係するユーザインタフェース詳細を示す図である。
【図4】[0025]本発明の特定の実施形態に係るトレースデータ視覚化に関係する説明文表示を示す図である。
【図5】[0026]表示されているイベントの長さを測定するために使用される時間軸を示す、本発明の特定の実施形態に係るトレースデータ視覚化に関係する例示的な表示を示す図である。
【図6】[0026]表示されているイベントの長さを測定するために使用される時間軸を示す、本発明の特定の実施形態に係るトレースデータ視覚化に関係する例示的な表示を示す図である。
【図7】[0027]要約されたデータのシステム負荷を表示するサムネイルペインを示す、本発明の特定の実施形態に係るトレースデータ視覚化に関係する例示的な表示を示す図である。
【図8】[0028]本発明の特定の実施形態に係るトレースデータ視覚化に関係するアクティビティグラフインタフェース表示を示す図である。
【図9】[0028]本発明の特定の実施形態に係るトレースデータ視覚化に関係するアクティビティグラフインタフェース表示を示す図である。
【図10】[0029]互いの上部に積み重ねられた２つの呼出しスタックグラフ表示を示す、本発明の特定の実施形態に係るトレースデータ視覚化に関係するユーザインタフェース表示を示す図である。
【図11】[0030]本発明の特定の実施形態に係るスレッド実行のトレースデータ視覚化に関係するユーザインタフェース表示を示す図である。
【図12】[0031]ガイド及びカーソルの詳細を示す、本発明の特定の実施形態に係るトレースデータ視覚化に関係するユーザインタフェース表示を示す図である。
【図13】[0032]選択詳細を示す、本発明の特定の実施形態に係るトレースデータ視覚化に関係するユーザインタフェース表示を示す図である。
【図14】[0033]ＴＩＭＥＭＡＣＨＩＮＥ（登録商標）カーソルの詳細を示す、本発明の特定の実施形態に係るトレースデータ視覚化に関係するユーザインタフェース表示を示す図である。
【図15】[0034]本発明の特定の実施形態に係る指定された時間範囲にトレースデータの視覚化を抑制することに関係するユーザインタフェース表示を示す図である。
【図16】[0034]本発明の特定の実施形態に係る指定された時間範囲にトレースデータの視覚化を抑制することに関係するユーザインタフェース表示を示す図である。
【図17】[0035]ターゲットが、本発明の特定の実施形態に従ってコードを実行していなかった期間を隠す又は示すユーザインタフェース表示を示す図である。
【図18】[0035]ターゲットが、本発明の特定の実施形態に従ってコードを実行していなかった期間を隠す又は示すユーザインタフェース表示を示す図である。
【図19】[0036]本発明の特定の実施形態に係るトレースデータ視覚化に関係する説明文表示を示す図である。
【図20】[0036]本発明の特定の実施形態に係るトレースデータ視覚化に関係する説明文表示を示す図である。
【図21】[0036]本発明の特定の実施形態に係るトレースデータ視覚化に関係する説明文表示を示す図である。
【図22】[0037]呼出しスタックグラフを示す、本発明の特定の実施形態に係るトレースデータ視覚化に関係するスレッド表示信号ユーザインタフェースを示す図である。
【図23A】[0038]本発明の特定の実施形態に係るトレースデータ視覚化に関係する追加のタスク表示信号ユーザインタフェースを示す図である。
【図23B】[0038]本発明の特定の実施形態に係るトレースデータ視覚化に関係する追加のタスク表示信号ユーザインタフェースを示す図である。
【図23C】[0038]本発明の特定の実施形態に係るトレースデータ視覚化に関係する追加のタスク表示信号ユーザインタフェースを示す図である。
【図24】[0039]本発明の特定の実施形態に係るトレースデータ視覚化に関係するズームインされたプロセッサ表示信号ユーザインタフェースを示す図である。
【図25】[0040]本発明の特定の実施形態に係るトレースデータ視覚化に関係するズームアウトされたプロセッサ表示信号ユーザインタフェースを示す図である。
【図26】[0041]本発明の特定の実施形態に係るトレースデータ視覚化に関係するプロセス複合ステータス表示信号を示す図である。
【図27】[0042]本発明の特定の実施形態に係るトレースデータ視覚化に関係する３つのステータス表示信号の相対的なアクティビティを示す図である。
【図28】[0043]ブックマークの詳細を示す、本発明の特定の実施形態に係るトレースデータ視覚化に関係するユーザインタフェース表示を示す図である。
【図29】[0044]ツールチップの詳細を示す、本発明の特定の実施形態に係るトレースデータ視覚化に関係するユーザインタフェース表示を示す図である。
【図30A】[0045]本発明の特定の実施形態に係るトレースデータ視覚化に関係する拡大されたツールチップ特徴を示す図である。
【図30B】[0045]本発明の特定の実施形態に係るトレースデータ視覚化に関係する拡大されたツールチップ特徴を示す図である。
【図31A】[0046]本発明の特定の実施形態に係るデータの処理及び要約の態様を示す例示的なハイレベル図である。
【図31B】[0046]本発明の特定の実施形態に係るデータの処理及び要約の態様を示す例示的なハイレベル図である。
【図31C】[0046]本発明の特定の実施形態に係るデータの処理及び要約の態様を示す例示的なハイレベル図である。
【図31D】[0046]本発明の特定の実施形態に係るデータの処理及び要約の態様を示す例示的なハイレベル図である。
【図32】[0047]本発明の特定の実施形態でレンダリングエンジン最適化を可能にする例示的なサマリストリームの特徴を示す図である。
【図33】[0048]本発明の特定の実施形態に係る表示信号の部分的に要約された例示的なログ及び対応する表現を示す図である。
【図34】[0049]本発明の特定の実施形態でファイルに書き込むことができるサマリエントリの態様を示す例示的な図である。
【図35】[0050]本発明の特定の実施形態に係るサマリレベルの作成の態様を示す例示的なハイレベル図である。
【図36】[0051]本発明の特定の実施形態に係る例示的なサマリバケツの態様を示す図である。
【図37A】[0052]Ｐｙｔｈｏｎ言語で作成された、本発明の態様に係る要約エンジンの実施形態を示す図である。
【図37B】[0052]Ｐｙｔｈｏｎ言語で作成された、本発明の態様に係る要約エンジンの実施形態を示す図である。
【図37C】[0052]Ｐｙｔｈｏｎ言語で作成された、本発明の態様に係る要約エンジンの実施形態を示す図である。
【図37D】[0052]Ｐｙｔｈｏｎ言語で作成された、本発明の態様に係る要約エンジンの実施形態を示す図である。
【図38A】[0053]本発明の特定の実施形態に係るデータ要約処理の例示的な未処理入力データストリーム及び対応するファイル出力を示す図である。
【図38B】[0053]本発明の特定の実施形態に係るデータ要約処理の例示的な未処理入力データストリーム及び対応するファイル出力を示す図である。
【図38C】[0053]本発明の特定の実施形態に係るデータ要約処理の例示的な未処理入力データストリーム及び対応するファイル出力を示す図である。
【図39】[0054]本発明の態様に係るデータ要約の例示的な詳細を示す図である。
【図41】[0056]本発明の態様に係るデータ要約の例示的な詳細の別の集合を示す図である。
【図43】[0058]本発明の特定の実施形態において任意のズームレベルでの効率的なレンダリングを可能にするデータ要約の態様を示す図である。
【図44】[0059]１ミリ秒で分けられる２つのデータ点が、百万秒の間毎秒出力される特定の実施形態に係るデータ要約の態様を示す図である。
【図45】[0060]トレースイベントが、多くの点と単一の点との間で交互に起きる特定の実施形態に係るデータ要約の態様を示す図である。
【図46】[0061]十億の点がそれぞれ１秒で分けられ、データのまさに最後で、百万点がそれぞれ１ナノ秒で分けられる、特定の実施形態に係るデータ要約の態様を示す図である。
【図47】[0062]本発明の特定の実施形態に係るトレースデータを検索するためのインタフェースを示す図である。
【図48】[0062]本発明の特定の実施形態に係るトレースデータを検索するためのインタフェースを示す図である。
【図49】[0063]本発明の特定の実施形態で検索されるイベントの数を削減するための技術を示す例示的なハイレベル図である。
【図50】[0063]本発明の特定の実施形態で検索されるイベントの数を削減するための技術を示す例示的なハイレベル図である。
【図51】[0064]本発明の特定の実施形態に従ってトレースデータを検索するためのインタフェースを示す図である。
【図52】[0064]本発明の特定の実施形態に従ってトレースデータを検索するためのインタフェースを示す図である。
【図53】[0065]本発明の特定の実施形態に係るトレースデータ視覚化に関係する関数呼出し表示を示す図である。
【図54】[0066]本発明の特定の実施形態に係るトレースデータ視覚化に関係する検索結果表示信号ユーザインタフェースを示す図である。
【図55】[0066]本発明の特定の実施形態に係るトレースデータ視覚化に関係する検索結果表示信号ユーザインタフェースを示す図である。
【図56】[0067]本発明の特定の実施形態に係る例示的なネットワーク化された環境、及びその関連構成要素を示す図である。
【図57】[0068]本発明の特定の実施形態の態様を実施するために使用されてよい、コンピューティングデバイスの例示的なブロック図である。
【図58】[0069]本発明の特定の実施形態の態様を実施するために使用されてよいネットワーク化されたコンピューティングシステムの例示的なブロック図である。
【発明を実施するための形態】
【0021】
[0070] 当業者は、本発明の以下の説明は例示的にすぎず、決して限定的ではないことを理解する。本発明の他の実施形態は、本開示の利点を有するとそうした当業者に対し、自らを容易に提案する。添付図面に示されるように、ここで本発明の具体的な実施態様に対して詳細に参照が行われる。同じ部分又は類似する部分を参照するために、図面及び続く説明を通じて、同じ参照番号が使用される。
【0022】
[0071] 特定の実施形態では、本発明の態様は、開発者が（１）任意のソフトウェア複雑度及びサイズの、（２）任意の長期間の実行時間を有する、及び／又は（３）プログラム実行の任意の大きいトレースを有するコンピュータプログラムの実行を視覚的に分析する、デバッグする、及び理解するのを手助けするために方法及びシステムを提供する。
【0023】
[0072]デバッグ／視覚化環境
[0073] 特定の実施形態では、本発明の態様に係るシステム及び方法は、（１）プログラム実行がどのようにして特定のシナリオ又は状態を生じさせたのか、（２）試験用のプログラムを含むさまざまなプロセスの実行に時間がどのようにして及びどこで使われるのか、並びに／又は（３）試験中のプログラムが予想外に実行しているかどうかを判断するのを支援するために、コンピュータシステムの実行中に収集されるトレースデータの視覚的な時間ベースの概要を提供する。
[0073] 特定の実施形態では、本発明の態様に係るシステム及び方法は、（１）プログラム実行がどのようにして特定のシナリオ又は状態を生じさせたのか、（２）試験用のプログラムを含むさまざまなプロセスの実行に時間がどのようにして及びどこで使われるのか、並びに／又は（３）試験中のプログラムが予想外に実行しているかどうかを判断するのを支援するために、コンピュータシステムの実行中に収集されるトレースデータの視覚的な時間ベースの概要を提供する。
【0024】
[0074] 特定の実施形態で、第１の質問（基本的には、「どうやってここにやってきたのか」）に応えるために、本発明の態様に係るシステム及び方法は、関数呼出し、コンテクストスイッチ、システムコール、割込み、及びカスタムログ（ｌｏｇｇｅｄ）イベントを制限なく含む、近年発生したトレースされたイベントのタイムラインを表示する。この質問に対する答えを可能な限り迅速に提供するために、すべてのトレースデータはログの終わりから逆順で要約され、視覚化ツールは、より多くのデータが分析されているにも関わらず部分的なトレースデータを表示する。
【0025】
[0075] 第２の質問（基本的には、「時間がどこで使われているのか」）に答えるために、各特定の実施態様の要件に応じて提供される場合がある他の方法及びシステムの中で、どのスレッドが実行中であるのか、スレッドはいつ及びどれほど長く実行しているのか、スレッドはいつ及びどのようにしてインタラクションするのか、並びにどの関数呼出しが最も多くの時間を要するのかを決定するための方法及びシステムが本発明の態様に従って提供される。
【0026】
[0076] 第３の質問（基本的には、「プログラムは予想されていない何かを行っているのか」）に答えるために、各特定の実施態様の要件に応じて提供される場合がある他の方法及びシステムの中で、ユーザが、特定の関数に対する呼出しの中に任意の外れ値があるかどうか、スレッドが期限内にその作業を完了したかどうか、イベントを取り扱うスレッドが、それが可能な限りすぐに予定されるかどうかを発見するのを手助けするための方法及びシステムが、本発明の態様に従って提供される。
【0027】
[0077] 大きい／複雑なプログラムのための視覚化システムに固有の典型的な問題に対処するいろいろな方法及びシステムが、本発明の態様に従って開発されてきた。制限なく、本書を通じてより詳細に説明されるように、これらの方法及びシステムは、以下の特徴の実装を容易にする。
１．異なるスレッド間のインタラクション及び関係性の視覚化
２．重要ではない情報の非表示／重要な情報の重視
３．ユーザがより詳しい検査のために興味のある領域を迅速に識別できるようにするやり方で大量のデータを表示すること
４．任意に大きいデータセットでの迅速な移動、及び最も関連性のある情報の重視による支援
５．同じデータセットで数ピコ秒から数十年までの時間スケールを取り扱うこと
６．任意の時間間隔で発生するイベントについて分析されたデータの効率的な記憶
７．任意のズームスケールでの何兆ものイベントを有するデータセットを迅速に表示すること
８．ツールがログデータを検査及び処理し続ける間にユーザがツールイベントを利用するためのサポート、及び
９．ツールがすべてのログデータを検査するのを待機する必要なく、ユーザが分析を始めることができるように最初に最も関連性のある情報を表示すること
１．異なるスレッド間のインタラクション及び関係性の視覚化
２．重要ではない情報の非表示／重要な情報の重視
３．ユーザがより詳しい検査のために興味のある領域を迅速に識別できるようにするやり方で大量のデータを表示すること
４．任意に大きいデータセットでの迅速な移動、及び最も関連性のある情報の重視による支援
５．同じデータセットで数ピコ秒から数十年までの時間スケールを取り扱うこと
６．任意の時間間隔で発生するイベントについて分析されたデータの効率的な記憶
７．任意のズームスケールでの何兆ものイベントを有するデータセットを迅速に表示すること
８．ツールがログデータを検査及び処理し続ける間にユーザがツールイベントを利用するためのサポート、及び
９．ツールがすべてのログデータを検査するのを待機する必要なく、ユーザが分析を始めることができるように最初に最も関連性のある情報を表示すること
【0028】
[0078] 図１は、ユーザが、システムがどのようにして特定の状態にたどり着いたのか（「どうやってここにやってきたのか」）を知ることを望んでいる、本発明の特定の実施形態の態様を示す例示的なハイレベル図である。図１に示されるように、１つ以上のコンピュータシステム上での１つ以上の例示的なプログラムの実行は、前方方向（矢印１４０を参照）で進行する。プログラムが実行するにつれ、イベントが発生し（例えば、イベント１００、１１０、１２０、及び１３０）、関連性のあるイベントに関するトレースデータが収集され、記憶される。デバッグ／分析段階では（つまり、図１の下部では）、イベントは、クラッシュ又はブレイクポイントで開始し（１３０）、特定の実施形態で逆の順序で処理される。本書の他の箇所で詳説されるように、イベントが分析され、要約されるにつれ（１６０）、イベントは、本明細書に詳細に説明されるように表示される（１５０）。
【0029】
[0079]履歴ユーザインタフェースの説明
[0080] 図２は、本発明の特定の実施形態に従ってトレースデータ視覚化の態様を実施する、「履歴ウィンドウ」と称するユーザインタフェースを示す。ボタン（２００）は、（選択されたボタンに応じて、ユーザがグラフペイン（２８５）内でクリックし、ドラッグするとき、ユーザがパンする、時間範囲を選択する、又はズームすることを可能にしてよい）クリックアンドドラッグモードで使用される。ブックマークされた選択は、他の箇所に説明されるように、領域２０５により示される。領域２１０は、以下により詳細に説明されるアクティビティグラフを含む。項目２１５は星ボタンであり、星２４０に関係しており、その両方とも他の箇所により詳細に説明される。フィルタ２２０は、フィルタ説明文を含む。グラフペイン（２８５）は、ガイド（２５５）、ＴＩＭＥＭＡＣＨＩＮＥ（登録商標）カーソル（２７０）、スレッドインタラクション矢印（２５０）、ナビゲーション矢印（例えば、２８０）、及び１つ以上の非表示のデバッグ時間インジケータ（２７５）をさらに含む。表示信号と呼ばれる一次データは、グラフペインを横切って水平に通る。図２は、プロセッサ（２２５）、プロセス（２３０及び２３５）、並びに呼出しスタックグラフ（２４５）を表す表示信号を含む。履歴ウィンドウは、グラフペイン（２８５）の下方に時間軸インジケータ（２６５）及びサムネイルペイン（２６０）を含む。これらのすべては、例示的な実施形態との関連で本書により詳細に説明される。
[0080] 図２は、本発明の特定の実施形態に従ってトレースデータ視覚化の態様を実施する、「履歴ウィンドウ」と称するユーザインタフェースを示す。ボタン（２００）は、（選択されたボタンに応じて、ユーザがグラフペイン（２８５）内でクリックし、ドラッグするとき、ユーザがパンする、時間範囲を選択する、又はズームすることを可能にしてよい）クリックアンドドラッグモードで使用される。ブックマークされた選択は、他の箇所に説明されるように、領域２０５により示される。領域２１０は、以下により詳細に説明されるアクティビティグラフを含む。項目２１５は星ボタンであり、星２４０に関係しており、その両方とも他の箇所により詳細に説明される。フィルタ２２０は、フィルタ説明文を含む。グラフペイン（２８５）は、ガイド（２５５）、ＴＩＭＥＭＡＣＨＩＮＥ（登録商標）カーソル（２７０）、スレッドインタラクション矢印（２５０）、ナビゲーション矢印（例えば、２８０）、及び１つ以上の非表示のデバッグ時間インジケータ（２７５）をさらに含む。表示信号と呼ばれる一次データは、グラフペインを横切って水平に通る。図２は、プロセッサ（２２５）、プロセス（２３０及び２３５）、並びに呼出しスタックグラフ（２４５）を表す表示信号を含む。履歴ウィンドウは、グラフペイン（２８５）の下方に時間軸インジケータ（２６５）及びサムネイルペイン（２６０）を含む。これらのすべては、例示的な実施形態との関連で本書により詳細に説明される。
【0030】
[0081] 図３は、本発明の特定の実施形態に係るトレースデータ視覚化に関係するユーザインタフェース詳細を示す。図３は、ここでは３００と称される、図２のグラフペイン（２８５）の異なるビューを提供する。グラフペイン（２８５／３００）は、特定の実施形態においてユーザのシステムで起こっていることの全体像を提供する。グラフペイン（２８５／３００）は、１つ以上の表示信号（例えば、信号３１０、３２０、３４０、３５０、及び３６０）を含む。信号は、任意のサイズを有するタイムスタンプを押されたトレースイベントのストリームを表す。グラフペインの右側の表示信号データはより最近である。左のデータはより最近ではない。特定の実施形態では、有利なことに、トレースイベントのタイムスタンプが押された性質は、ユーザによって選択される表示ズームレベルに関わりなく時間が同期した方法で、グラフペイン（２８５／３００）、又は他の関連性のある表示に示されるさまざまな信号を表示するために使用される。
【0031】
[0082] 説明文は、特定の実施形態（例えば、図４の説明文表示を参照すること）ではグラフペインに示される表示信号を一覧表示し、説明文はグラフペインに縦のスクロールバー（４００）を提供する。表示信号は、該当する場合、階層的に並べられる。例えば、スレッドは、スレッドを含むプロセスの下でグループ化される。特定の実施形態では、スレッド表示信号の名前の隣のプラス符号（＋）は、例えば呼出しスタックグラフ等のそのスレッドに関係する追加の情報が表示に利用可能であることを示す。プラス符号をクリックすると、データが表示される。
【0032】
[0083] 特定の実施形態では、時間軸（例えば、図５を参照すること）は、ユーザが、特定のイベントがいつ発生したのかを判断するのを手助けする。時間軸は、グラフペインに現在表示されているタイムスタンプが押された又は時間が同期したログ又はトレースデータのシステム時間又はローカル時間を表示する。時間軸の左下角に表示される値は、ベース開始時間を提供する。ユーザは、（たとえあったとしても）ベース開始時刻のＸｓの代わりにインクリメント値を使用することによって軸に沿った任意の点での時刻を推定できる。例えば、図５の１７：０３：ＸＸ．Ｘｓのベース開始時刻を所与として、カーソルの推定時刻は、２０１４年１２月３１日、太平洋標準時刻１７時３分８．５秒である。ＴＩＭＥＭＡＣＨＩＮＥ（登録商標）デバッガが特定の実施形態で実行制御動作を処理している場合、動作が進行中である（例えば、図６を参照すること）を示すために、動画化された緑の矢印及び白の矢印（又は他の適切な色付きの視覚インジケータ）が時間軸に表示される。特定の実施形態では、時間軸は、他の単位の情報を示してよい。例えば制限なく、時間軸の代わりに、メモリ割振り軸、キャッシュミス軸、又は移動距離軸、又は使用電力軸があるであろう。時間以外の単位に関する追加の情報は、以下により詳細に説明される。概して、本書は、イベントが相互に関連付けられる、軸（又は、実行の単位）として時間を使用する実施形態を説明する。しかしながら、当業者は、他の実行の単位に同じ原理を適用する方法を容易に理解する。
【0033】
[0084] 特定の実施形態では、サムネイルペインは、トレースデータが要約されている間プログレスバーを示す。プログレスバーはサムネイルペインに表示され、要約プロセスが終了するのにどのくらい長く要するのかの推定値を提供するだけではなく、まだ分析されていないこと（例えば、図７を参照）と比較して、分析済みのトレースされた時間の相対的な量を示す。
【0034】
[0085]異なる表示信号のイベントがどのようにして互いと関係するのかを確認すること
[0086] 特定の実施形態では、アクティビティグラフが、すべてのスレッド表示信号グラフを互いの上に積み重ねる（例えば、図８に示されるアクティビティグラフを参照すること）。アクティビティグラフの各色は、ユーザがシステム負荷に対する各スレッドの寄与を確かめることができるように異なるスレッドを表す。アクティビティグラフでスレッドに割り当てられる色は、グラフペイン表示がプロセッサ表示信号上でズームインされるときスレッドに使用される色と同じである。グレーの着色は、個々のプロセッサ活用が、別個の着色セクションを示すことを保証するほど十分に大きくない全スレッドの集合的なプロセッサ活用を示す。特定の実施形態では、これは、スレッドの実行が、１未満のピクセルに相当する垂直空間を要するときに発生する（実行単位時間軸ではなく、値軸を参照しているので、これはピクセル実行単位ではないことに留意されたい）。特定の実施形態は、それぞれが、グレー領域を示す代わりに、１未満のピクセルを表す、基本的なスレッドの色を混合してよい。特定の実施形態では、ユーザは、関連付けられたスレッド及びプロセス名を有するツールチップを見るために（グレー領域ではなく）着色した領域上をホバリングしてよく、ユーザは、グラフペイン（例えば、図９を参照すること）内の関連付けられたスレッドを見るために着色した領域をクリックしてよい。特定の実施形態では、アクティビティグラフは、それがグラフペインの一部でなくても、グラフペイン内のデータと時間で相互に関連付けられる。
[0086] 特定の実施形態では、アクティビティグラフが、すべてのスレッド表示信号グラフを互いの上に積み重ねる（例えば、図８に示されるアクティビティグラフを参照すること）。アクティビティグラフの各色は、ユーザがシステム負荷に対する各スレッドの寄与を確かめることができるように異なるスレッドを表す。アクティビティグラフでスレッドに割り当てられる色は、グラフペイン表示がプロセッサ表示信号上でズームインされるときスレッドに使用される色と同じである。グレーの着色は、個々のプロセッサ活用が、別個の着色セクションを示すことを保証するほど十分に大きくない全スレッドの集合的なプロセッサ活用を示す。特定の実施形態では、これは、スレッドの実行が、１未満のピクセルに相当する垂直空間を要するときに発生する（実行単位時間軸ではなく、値軸を参照しているので、これはピクセル実行単位ではないことに留意されたい）。特定の実施形態は、それぞれが、グレー領域を示す代わりに、１未満のピクセルを表す、基本的なスレッドの色を混合してよい。特定の実施形態では、ユーザは、関連付けられたスレッド及びプロセス名を有するツールチップを見るために（グレー領域ではなく）着色した領域上をホバリングしてよく、ユーザは、グラフペイン（例えば、図９を参照すること）内の関連付けられたスレッドを見るために着色した領域をクリックしてよい。特定の実施形態では、アクティビティグラフは、それがグラフペインの一部でなくても、グラフペイン内のデータと時間で相互に関連付けられる。
【0035】
[0087] 図１０は、本発明の特定の実施形態に係るトレースデータ視覚化に関係する（互いの上に積み重ねられた２つの呼出しスタックグラフを示す）スレッド表示信号ユーザインタフェースを示す。図１０に示されるように、特定の実施形態では、複数の呼出しスタックグラフは、ズームレベルに関わりなく、水平（時間）軸を横切る完全時間同期で同時に示されてよい。この特徴は、例えば、複数のプロセッサが同時にスレッド又は関数を実行する完全対称型マルチプロセッサシステム（ＳＭＰ）デバッグ環境等の特定の実施形態で有利である。
【0036】
[0088] グラフペイン表示がズームインされるとき、特定の実施形態では、スレッド表示信号は、システムコール（図１１の１１０５）、スレッドインタラクション（同図の１１００）、及びコンテクストスイッチを制限なく含む詳細なスレッドステータスデータを示す。多くの場合、最も重要なスレッドについての１個の情報は、その実行ステータスである。これを詳しく説明するために、太いステータス線又は細いステータス線が使用される。スレッドが実行していないとき、細い線は、スレッド表示信号（例えば、図１１の領域１１３０及び１１２５）に表示される。特定の実施形態では、細い線の着色は、スレッドがなぜ現在実行中ではないのかの理由を示す。例えば、特定の実施形態では、黄色は、スレッドがブロックされていること（例えば、図１１の領域１１３０）を意味し、緑色は、スレッドが実行する準備が完了している（例えば、同図の領域１１２５）ことを意味する。スレッドが実行しているとき、太いバーが表示される（例えば、図１１の領域１１４０及び１１１５）。マルチプロセッサシステムに関する特定の実施形態では、スレッドが実行していたプロセッサの数はこのバーに表示され、バーに使用される色を決定する。異なる色は、ユーザが、スレッドがプロセッサ間で遷移した時点を選び出すことを可能にする。多くの遷移は、コンテクストスイッチオーバヘッド、キャッシュの使用における潜在的な非効率等を示す場合がある。
【0037】
[0089] 特定の実施形態では、実行状態の色は、実行中のコードの種類を示すために改変できる。例えば、図１１では、１１４０及び１１１５で表される範囲は太く、スレッドが実行中であることを示す。しかしながら、１１４５及び１１２０では、色はより暗く、これは特定の実施形態では、スレッドがユーザコードを実行中であることを示す。１１３５及び１１１０では、色はより明るく、カーネルがスレッドの代わりにコードを実行していることを示す。ＳＭＰシステムでは、ロックを待機しているカーネルで使われる時間は、別の色で示されてよい。
【0038】
[0090] 異なるスレッド間のインタラクション及び関係の視覚化を容易にするために、本発明の実施形態は、「呼出しスタックグラフ」内のスレッドの呼出しスタックの視覚化を提供する。これらの呼出しスタックグラフは、時間（又は特定の実施形態では、実行の単位の他の表現）の観点からプログラムの関数流れを示す。ユーザインタフェースは、各スレッドが独自の呼出しスタックグラフと関連付けられるように分離された複数の呼出しスタックグラフを示す。特定の実施形態では、呼出しスタックグラフのスレッド通信アイコンは、あるスレッドがどこで別のスレッドとインタラクションするのかを視覚的に示す。これは、必要に応じて他のスレッドへの迅速なナビゲーションを容易にする。そうしたスレッドインタラクションの例は、制限なく、（例えば、あるスレッドが別のスレッドにデータを送信するとき等）スレッド間の直接的な通信、及び（例えば、あるスレッドが、別のスレッドがブロックされているセマフォ又は相互排除をリリースし、それによってブロックされているスレッドをウェークアップするとき等）間接的な通信を含む。例えば、図１０では、矢印１０００、１０１０、及び１０２０が、スレッド間の３つの通信点を指摘する。特定の実施形態では、追加のインジケータは、どのスレッドが通信しているのかを明らかにする。これは、ユーザが通信インジケータアイコンの上にマウスを位置決めするときに表示される矢印（図１０の１０３０）によって明示される。
【0039】
[0091] 上述されたスレッドアクティビティグラフは、ユーザが、興味がある点とほぼ同時にどのスレッドが実行していたのかを確認し、任意のそうしたスレッドに迅速にナビゲートできるようにする。特定の実施形態は、アクティビティグラフでのスレッドの表現のクリックが、グラフペインにスレッドを示すことを可能にする。
【0040】
[0092] 特定の実施形態では、図１２に示されるように、ガイド（１２００）は、ユーザがイベの時刻を推定し、２つのイベントが同時に発生したかどうかをより容易に判断し、２つの近いイベントの時間順を決定するのを手助けする。これは、データエントリがグラフペイン内で多くの垂直空間により分けられるときに役に立つ場合がある。特定の実施形態では、グラフ（１２００）はマウスに従う。特定の実施形態では、カーソル（１２１０）は、その位置が、ユーザが新しい場所でシングルクリックするまで静的であることを除き、ガイド（１２００）に類似している。特定の実施形態では、カーソル及び選択は相互に排他的である。特定の実施形態では、選択（例えば、図１３に示される領域１３００）は、特定のアクションがどの時間範囲に制限されるのかを示す。また、選択を行うことは、２つのイベント間の時間を測定する優れた方法でもあり、選択（１３１０）の持続時間は、グラフペインの下部に表示される。
【0041】
[0093] 特定の実施形態でのＴＩＭＥＭＡＣＨＩＮＥ（登録商標）カーソル（例えば、図１４の項目１４００を参照すること）は、（該当する場合）ＴＩＭＥＭＡＣＨＩＮＥ（登録商標）デバッガでのユーザの場所を正確に示す。ＴＩＭＥＭＡＣＨＩＮＥ（登録商標）デバッガが実行中である場合、ＴＩＭＥＭＡＣＨＩＮＥ（登録商標）カーソルは緑であり、それが休止している場合青である。ＴＩＭＥＭＡＣＨＩＮＥ（登録商標）カーソルは、プロセッサ表示信号、及びＴＩＭＥＭＡＣＨＩＮＥ（登録商標）デバッグのために構成されているプロセスに属する表示信号でのみ表示される。マルチプロセッサシステムでは、ＴＩＭＥＭＡＣＨＩＮＥ（登録商標）実施態様の特定の実施形態は、異なる時間又はプロセッサを表す必要がある場合がある。結果として、ＴＩＭＥＭＡＣＨＩＮＥ（登録商標）カーソルは、すべてのプロセッサ及びスレッド全体で時間の統一された瞬間にマークを付けない可能性がある。
【0042】
[0094]提示される情報量の削減
[0095] デバッグ／視覚化ツールを使用する開発者は、多くの場合、目の前の使用事例に集中し、理解する能力と干渉する場合があるいくつかのクラスの重要ではない情報に遭遇する。本発明の態様によれば、この情報を削減するためのシステム、方法、及び技術は、情報のメイン表示に対してだけではなく、ツールが特定の実施形態で提供するいろいろな検索機能及び分析機能に対しても適用されてよい。
[0095] デバッグ／視覚化ツールを使用する開発者は、多くの場合、目の前の使用事例に集中し、理解する能力と干渉する場合があるいくつかのクラスの重要ではない情報に遭遇する。本発明の態様によれば、この情報を削減するためのシステム、方法、及び技術は、情報のメイン表示に対してだけではなく、ツールが特定の実施形態で提供するいろいろな検索機能及び分析機能に対しても適用されてよい。
【0043】
[0096] 重要ではない情報は、ユーザにとって興味深くない実行情報を含む時間の範囲を含んでよい。本発明の態様によれば、ユーザは、興味のある時間の範囲を指定し、表示及び検索の結果からその範囲外のすべてを除外できる。例えば、１５００と名前が付けられたボタンが、ビューを選択された時間の範囲に抑制するためにクリックされるところである図１５、及び１６００及び１６１０が、表示には含まれていない抑制されたビューのどちらかの側に追加データがあることを示すために淡色表示される図１６を参照すること。
【0044】
[0097] また、重要ではない情報は、分析されているプログラムが、それがデバッグのために停止されたために実行していなかった時間の範囲を含む場合もある。本発明の態様によれば、特定の実施形態では、時間カットモードが、ツールに、プログラムが休止されていた時間の範囲を折り畳ませ、それらの時間範囲はそうでなければ画面上で可視であるであろう。時間範囲は、重要ではない時間が表示から削除されていることを示すために細い線で置き換えられる。これが、プログラムがデバッガによって休止されていなければ、それが見えたであろうように見える実行履歴を表示させる。特定の実施形態では、例えばスレッドの集合が実行していなかったすべてのとき等、他の種類の時間を除外するために類似する手法がとられる。例えば、赤い線が、時間が１７１０でカットされていることを示す図１７を参照すること。この手法が、スレッドの選択された部分集合が実行している又は実行していない時間を除外するためにも適用できることに留意されたい。
【0045】
[0098] 図１８は、時間カットが無効にされるとき、同じビューがどのように見えるのかを示す。同じ時間の範囲が表示される。つまり、図１８では、１８００は、図１７が１７００と名前を付ける時間の範囲に名前を付け、１８２０は、図１７が１７２０と名前を付ける時間の範囲に名前を付ける。しかしながら、図１７から非表示にされている（つまり、カットされている）時間の範囲は、陰影が付けられたピンクの領域（１８１０）として図１８に示される。
【0046】
[0099] また、重要ではない情報は、目の前の問題に関連性のないスレッドの関数実行情報を含んでもよい。特定の実施形態でこの課題に対処するために、各スレッドは、その実行情報を表示するための独自の領域を割り当てられる。
【0047】
[0100] また、重要ではない情報は、呼出しスタックグラフに表示されるとき、画面を埋め、このようにして他の潜在的に有用な情報が表示されるのを妨げる呼出しスタックの深いレベルの時間の範囲を含んでもよい。特定の実施形態では、ユーザは、スレッド表示信号の右下角に表示されるリサイザボックス（例えば、図３のボタン３３０を参照すること）をダブルクリックすることによって、スレッドの呼出しスタックグラフの高さのサイズを変更することができる。ユーザは、次いで再びリサイザボックス（３３０）をダブルクリックして、スレッドの呼出しスタックグラフを拡大し、その完全な高さに戻してよい。スレッドの呼出しスタックグラフのサイズを手動で変更するためには、ユーザは、リサイザボックス（３３０）をクリックしてドラッグし、圧縮するために上方に移動し、拡大するために下方に移動する。そうした実施形態では、呼出しスタックグラフの部分のサイズが削減されても有用な情報を示し続けるために、呼出しスタックグラフが要求されたサイズの中に収まるまで以下のステップが適用される。つまり（１）現在表示されている時間範囲で何も起こっていない呼出しスタック深さが削除される、（２）画面全体に及ぶ呼出しスタック深さが、それらは興味がないと仮定されるので折り畳まれる（圧縮された領域上のツールチップが折り畳まれた関数のリストを示す）、（３）要約された情報しか含んでいない（ピクセル実行単位あたりの複数の呼出し又は戻り）呼出しスタック深さが折り畳まれる、及び／又は（４）残りの呼出しスタック深さがランク付けされ、その関数サイズがどれほど密接に最善の関数サイズに適合するのかに従って排除される。具体的には、残りの呼出しスタック深さごとに、サイズが設定サイズに最も近い関数が、その深さの最善のサイズの関数として使用される。（設定サイズは、プログラムの関数名で検出される平均文字数、又は固定文字数である場合もあれば、設定サイズは実施態様の要件に応じてなんらかの他の測定基準に基づく場合もある。）呼出しスタック深さは、次いでその最善の関数が全体的な最善にどの程度密接に適合するのかに基づいてランク付けされ、深さは最悪から最善に排除される。
【0048】
[0101] また、重要ではない情報は、ユーザにとって興味深くない表示信号を含む場合もある。特定の実施形態では、この課題は、ユーザにそうした表示信号を単一行に折り畳む、又はそうした表示信号を表示されている信号の説明文の中に非表示にする能力を与えることによって対処される。
【0049】
[0102] 特定の実施形態では、フィルタは、説明文エントリを、その名前がユーザによって指定される文字列を含むそれらの表示信号に制限する。例えば、１９００で「ｄｒｉｖｅｒ」を指定する図１９を参照すること。また、親及び子は、特定の実施形態でのコンテクストのために表示される。具体的には、特定の実施形態では、説明文は、メインウィンドウが表示しているさまざまなスレッド及び表示信号の階層構造を示す。例えば、プロセスは、複数のスレッドを含む場合がある。従って、プロセスはそれらのスレッドの親であると見なされる。同様に、スレッドは、その中に複数の表示信号を有してよく（例えば、変数値は、スレッド単位で追跡されてよい）、それらの表示信号は、それ自体がプロセスの子である場合があるスレッドの子であると見なされる。エントリが特定の実施形態で説明文から除外されるとき、グラフペインの対応する表示信号も除外される。ユーザが興味がない表示信号を除外することは、ユーザが、画面及び表示スペースの大部分を生かすことができるようにする。それは、ユーザが特定の表示信号を見つけるのにも役立つ場合がある。
【0050】
[0103] このようにして、説明文は、特定の実施形態では表示信号名別にフィルタにかけることができる。これは、ユーザが、特定の使用状況で自分に関連性がある少ない表示信号に集中できるようにする。
【0051】
[0104] 特定の実施形態では、星は、ユーザが、説明文で興味がある表示信号にフラグを立てることを可能にする。例えば、図２０で、スレッド「初期」が星を付けられる（２０１０）。星ボタン（２０００）がクリックされるとき、星ボタンは、説明文及びグラフペイン内の星が付けられた表示信号（並びにその親及び子）の独占的な表示をトグルし、ここでは図２１を生じさせる。フィルタのように、この機能は、ユーザが画面スペースの大部分を生かすことを可能にする。
【0052】
[0105] このようにして、ユーザが明白に興味がある表示信号は、特定の実施形態においてマークを付け（つまり、星を付け）られてもよく、次いでそれらの表示信号だけが示されてよい。特定の実施形態では、ユーザが（例えば、スレッド転送アイコンをクリックすることによって）現在示されていない別の表示信号からのデータに対する興味を表すとき、その表示信号は自動的にマークを付けられ、説明文に含まれる。
【0053】
[0106] 特定の実施形態では、最も関連性のある情報を含んでいるように見える表示信号を選択するために発見的方法が実施される。この種の特定の例示的な実施形態では、例えば、時間範囲が選択される場合、次いで（１）選択された時間範囲中にイベントが発生しなかった表示信号が表示から除外／削除される、（２）総時間のうちのほんのわずかの間実行したスレッドは説明文で維持されるが、星は付けられない、及び（３）残りのスレッド及びイベントが星を付けられる。例えば、表示信号を含める又は除外するために検索結果を使用する等の追加の発見的問題解決法が適用されてよい。上記技術の組合せは、各実施態様の特定の要件に応じて使用されてよい。
【0054】
[0107] 時間範囲が特定の実施形態で選択されない場合、上述された同じアルゴリズムが、つねにではないが実行される。さらに、任意のプロセッサで実行する最後のスレッドは、これらのスレッドの１つ以上が、ユーザがより詳細に探究することに興味があるイベントをおそらくトリガしたと仮定して、自動的に含められる。
【0055】
[0108]人間が理解可能な様式での大量のデータの表示
[0109] 本発明の態様によれば、ユーザがより詳しい検査のために興味のある領域を迅速に識別できる方法で大量のデータの表示を容易にするための方法、システム、及び技術が提供される。人間は大量（潜在的にテラバイト）の未処理トレース情報を容易に分析できず、しかもプログラムのきわめて詳細な性質を所与として、プログラムについての非常に詳細な情報を確かめることが多くの場合重要である。人間が、すべての情報を通して直線的に検索することは不可能であるため、ユーザが自分の注意を集中できる興味のある点をほのめかすことはきわめて重要である。この問題を解決するのを手助けするために、特定の実施形態は、上記に及び本書を通して概略されるように、ユーザに時間、空間、及び表示信号のドメインでデータの量を削減する数々の機能を提供する。
[0109] 本発明の態様によれば、ユーザがより詳しい検査のために興味のある領域を迅速に識別できる方法で大量のデータの表示を容易にするための方法、システム、及び技術が提供される。人間は大量（潜在的にテラバイト）の未処理トレース情報を容易に分析できず、しかもプログラムのきわめて詳細な性質を所与として、プログラムについての非常に詳細な情報を確かめることが多くの場合重要である。人間が、すべての情報を通して直線的に検索することは不可能であるため、ユーザが自分の注意を集中できる興味のある点をほのめかすことはきわめて重要である。この問題を解決するのを手助けするために、特定の実施形態は、上記に及び本書を通して概略されるように、ユーザに時間、空間、及び表示信号のドメインでデータの量を削減する数々の機能を提供する。
【0056】
[0110] 特定の実施形態では、呼出しスタックデータは、呼出しスタックグラフ（例えば、図２２を参照すること）のグラフペインに示される。図２２に示される呼出しスタックグラフのような呼出しスタックグラフは、ユーザがプログラムの実行経路を分析できるように経時的に呼出しスタックを示す。すべての関数間の関係性を表示することに加えて、特定の実施形態での呼出しスタックグラフは、各関数が呼び出される回数、及び呼び出される関数ごとの実行時間を追跡する。呼出しスタックグラフは、各実施態様の要件に応じて、デバッグ、性能分析、又はシステム理解のためのツールとして活用されてよい。
【0057】
[0111] 特定の実施形態では、例えば図２２に示される呼出しスタックグラフのようなグラフィック呼出しスタックグラフは、ユーザがプログラムの実行経路の異常を検索できるようにする。表示画面上の関数の表された幅は、関数が実行に費やした相対的な時間を示す。結果として、高価な関数は安価な関数よりも目立つ傾向がある。また、呼出しスタックグラフは、各関数のために従事される作業量を示すことによって特定の実施形態での作業の分散を明らかにする。ユーザは、どの関数が外れ値であるのか、又はそうでない場合予想外であるのかを確かめると、ユーザは、何が行われるべきなのかを判断するためにより密接に関数を調べることができる。ユーザは、ユーザが呼び出すべきではない関数を呼び出す関数を見つける可能性がある、又はユーザは逆―ユーザが呼出しを行うべきである呼出しを行っていない関数―を見つけ出す可能性がある。また、呼出しスタックグラフ（図２２）は、見慣れないコードがどのように機能するのかを判断するため―特に、スレッド境界の中の及びスレッド境界を横切る異なる構成要素がどのようにインタラクションするのかを確かめるための―ツールとして特定の実施形態で使用される場合もある。
【0058】
[0112] スレッドが特定の実施形態で実行しているとき、図２２の領域２２１０及び２２３０に示されるように、呼出しスタックグラフ内の色は飽和している。対照的に、スレッドが実行していないとき、呼出しスタックグラフ内の色は、同図の領域２２００及び２２２０に示されるように非飽和である。これは、ユーザがスレッドステータス情報を検査する必要なく、ユーザが、特定の関数がプロセッサ上で命令を実行していない領域を迅速に識別するのを手助けする。
【0059】
[0113] 関数は、呼び出される特定のインスタンスに基づいて特定の実施形態で着色される。従って、同じ関数が可視時間範囲で２度表示される場合、該関数は毎回同じ色を有する。大きいプログラムにある関数の数よりも利用できる区別可能な色はより少ない。それにも関わらず、この手法はほぼつねに、実行中の同じ関数のありそうなケースに目を引きつける。これは特に、同じ関数、つまり関数の同じシーケンスがどこで何回も実行されたのかを確かめるために、又は関数実行のそれ以外の場合規則正しいパターンでの偏差を選び出すために役立つ。
【0060】
[0114] 特定の実施形態では、データは、高いレベルの情報が示されるようにグループ化され、層化される。そうするためのいくつかの方法は、本書の他の箇所で詳説される。例は、以下を含む。（１）折り畳まれたプロセスは、それらの中の任意のスレッドがいつ実行していたのか、及びいつ任意のイベントが発生したのかを表示する要約を示してよい、（２）折り畳まれたスレッドは、それらがいつ実行していたのか（又は実行していなかったのか）を示す場合があり、折り畳まれたスレッドは、高いレベルのシステム及び通信イベントを表示してよい、及び／又は（３）他の記録されたイベントは階層にグループ化されてよく、階層は折り畳まれるとき、階層内に存在するすべての情報をグループ化してよい。ユーザは、より具体的な情報を入手するために高いレベル情報を調査又は展開してよい。
【0061】
[0115] 特定の実施形態では、複数のトレースイベントが単一のピクセル実行単位によってカバーされる期間内に発生するとき、レンダリングエンジンは（数、文字列、呼出しスタック情報、関数の入口／出口情報等を含む）異なる種類のトレースイベントを表示するために異なる方法を使用する。目的は、複数のイベントの視覚的に有用な表現を表示することである。いくつかの例が続く。
【0062】
[0116] 特定の実施形態では、表示が十分遠くでズームインされるとき、着色された太いバーは、スレッドがいつ実行していたのかを示し、細いバーは、スレッドがいつ実行していなかったのかを示す（図１１）。しかしながら、スレッドが所与のピクセル実行単位で実行していた及び実行していなかったの両方となるように表示がさらに遠くにズームアウトされるとき、表示は、そのピクセル実行単位（図２３Ａ）によってカバーされる時間の範囲の実行時間のパーセンテージを示す可変高さバーを示す。バーの色は、スレッドがそのピクセル分の時間実行したプロセッサのそれぞれの色のブレンドである。これは、例えばスレッドがおもに単一プロセッサで実行していたのか、それともプロセッサ間で切り替えていたのか等の高いレベルの傾向を確かめるのを容易にする。
【0063】
[0117] 特定の実施形態では、数値であるトレースイベントはプロットで表示される。イベントが別のイベントにごく接近して表示されないとき、その値は点として描かれ、文字列として印刷される。（文字列は、対応する点に沿ったプロットに表示される。）イベントが別のイベントにごく接近して表示され、これにより値の文字列が、もし印刷されるならばプロットの点に重複するであろうとき、値は印刷されない。２つ以上のイベントがピクセル実行単位によってカバーされる時間の範囲で表示されるとき、特定の実施形態では、その時間の範囲の最小値及び最大値が、その期間の中に含まれる値の範囲を示すために表示される。例えば、ピクセル実行単位によってカバーされる時間の範囲に含まれる最小値と最大値との間の範囲内に１つの色、及びその範囲の外に第２の色を有する縦のバーが表示される場合がある。この例の実施態様は、図２３Ｂに示される。特定の実施形態では、この表示は、平均、中央値、モード、標準偏差、又はピクセル実行単位によってカバーされる時間範囲内の値についての他の統計情報を示すために拡大される。
【0064】
[0118] 特定の実施形態では、数値であるトレースイベントは、（データプロットに表示される代わりに）テキストとしても表示できる。表示がズームアウトされ、表示がテキストが可読ではなくなるように大きい時間範囲に及ぶとき、おそらく複数のトレースイベントが互いに対して非常に密接に発生する、又は複数のトレースイベントが表示上で単一のピクセル実行単位で発生するため、ユーザが値及び他の値に対する関係性をまだ推論し得るように値を表示するための代替の方法が望ましい。各値は、時間範囲全体の又は（もしあれば）隔離された時間範囲の現在の最小値及び最大値に基づいた色を割り当てられる。描かれた値の色は、該最小値から該最大値に及ぶマッピングに基づいて決定される。このマッピングは、最小値と最大値との間に円滑な色の階調があるように設定される。つまり、徐々に大きくなる値は、それが高いレベルで見られるとき円滑に変化する色バンドとして表示される。
【0065】
[0119] いくつかの実施形態では、文字列であるトレースイベントも表示できる。各トレースイベントは色を割り当てられる。特定の実施形態では、色は、文字列のコンテンツに基づいている。つまり、同じ文字列の各インスタンスは同じ色で表示される。色のブロックは、同じ文字列の連続インスタンスを示す場合がある。例えば、図２３Ｃで、ピンクに着色される（２３５０）表示信号の部分は、頻繁に及び示されている時間範囲の間中断なしに発生している可能性がある特定の文字列を表す。同様に、緑に着色される（２３６０）表示信号は、頻繁に及び示されている時間範囲の間中断なしに発生している可能性がある異なる文字列を表す。特定の実施形態では、複数のトレースイベントが所与の表示信号の中で発生するとき、所与のピクセル実行単位では、ピクセル実行単位に含まれるピクセルの色は、すべての基本的なトレースイベントの色のブレンドである。近接する多くのピクセル実行単位が要約され、色が混合されたデータを示すとき、ユーザが、例えば頻繁に繰り返す文字列のシーケンス、繰り返す文字列のシーケンスからの逸脱、及びある反復する文字列のシーケンスから別の文字列のシーケンスへの変化等の高いレベルのパターンを確かめるのは比較的に容易になる。逆に、図２３Ｃの表示信号２３７０においてのように、パターンは明らかでない場合がある。これは、文字列が規則正しいシーケンスで発生していないことを意味する場合がある。
【0066】
[0120] 特定の実施形態では、複数の関数呼出しが所与の呼出しスタックレベルの中で発生するとき、所与のピクセル実行単位では、ピクセル実行単位に含まれるピクセルの色は、すべての基本的な関数の色のブレンドである。近接する多くのピクセル実行単位が、要約された色混合データを示すとき、例えば頻繁に繰り返す呼出しのシーケンス、繰り返す呼出しのシーケンスからの逸脱、ある繰り返す呼出しのシーケンスから別の繰り返す呼出しのシーケンスへの変化、及びおそらく同じ呼出しスタックレベル又は異なる呼出しスタックレベルで繰り返される呼出しの類似するシーケンス等の高いレベルのパターンを確かめることは比較的に容易になる。
【0067】
[0121] 特定の実施形態では、呼出しスタックグラフの一部分でレンダリングされた呼出しスタックの高さは、興味があるイベントが発生した領域を迅速に識別するために使用できる。この視覚化方法は、周期的な動きを識別するためと、外れ値を識別するための両方に有用であり、呼出しのシーケンスはそのピアよりもより深い又はより浅い。
【0068】
[0122] グラフペイン表示がズームインされるとき、特定の実施形態で、プロセッサ表示信号（例えば、図３の３１０）は、任意の時点でどのスレッド又は割込みが特定のプロセッサで実行していたのかを示す。より詳細で、表示信号ラベル２４４０、及び異なるように着色されたスレッド２４００、２４１０、２４２０、及び２４３０を含む、ズームインされた例は、図２４に示される。特定の実施形態では、同じ色は、スレッド又は割込みのために、それが毎回表示されるたびに使用されるが、通常、表示のために使用可能な容易に区別可能な色の数は限られているため、色は複数のスレッド又は割込みに使用されてよい。グラフペイン表示が特定の実施形態でズームアウトされるとき、各プロセッサ表示信号は、プロセッサ負荷データをサマリに示すグラフを表示する。表示信号ラベル２５１０及びプロセッサ負荷データ表示２５００を含む例が、図２５に示される。図２５に示されるように、たとえ個々のスレッドが実行しているのを見ることができないように表示がズームアウトされても、トレースデータの中で高いレベルパターンを見ることは依然として可能である。これは、プロセッサ表示信号の中のグラフの高さがプロセッサ負荷を表し、使用される色が、どのスレッドが可視時間範囲中に実行していたのかの表示を与えるためである。
【0069】
[0123] 特定の実施形態では、スレッド表示信号は、それらの包含プロセスの下の説明文でグループ化される。グループ化された要素に＋／－ツリーを使用する共通のインタフェース規約は、ユーザが包含プロセスを縮小させることを可能にする。この結果、説明文によりコンパクトな表現が生じる。これが特定の実施形態で行われるとき、プロセス表示信号は、いつプロセスの中の任意のスレッドが実行していたのかを示す複合ステータス表示信号を示す。それは、任意のスレッドがそのピクセル実行単位によってカバーされる時間範囲の中で実行していた時間のパーセンテージに従って、ピクセル実行単位に含まれるピクセルのパーセンテージを着色することによって複合ステータス表示信号を示す。図２６は、折り畳まれているＶＮＣＳｅｒｖｅｒ（２６４０）と名付けられたプロセスのための例の複合ステータス表示信号を示す。ラベル２６００の回りに、少量のスレッド実行がある。２６１０の回りで、プロセスの中のスレッドはよりアクティブになり、時間の５０％と同程度実行することもある。２６２０の回りで、プロセスの中のスレッドは、２６３０の回りで再びおもにイナクティブになる前に時間のほぼ１００％実行する。
【0070】
[0124] すべての表示信号が特定の実施形態で縮小されるとき、複合ステータス表示信号は、どのプロセスがいつでもアクティブであったのかを示す。これは、その相対的なアクティビティレベルを時間の関数として見ることを容易にする。図２７は、縮小された３つのプロセスを示す。第１―カーネル―は、それが実行を停止する前に２７００～２７１０まで時間のほぼ１００％実行していた少なくとも１つのスレッドを含む。カーネルアクティビティが低下したとき、ｉｐ４ｓｅｒｖｅｒ＿ｍｏｄｕｌｅは、ＶＮＣＳｅｒｖｅｒ（２７３０）が行ったように、それが過去（２７２０）に行ったよりも多く実行を開始した。特に、ＶＮＣＳｅｒｖｅｒは、時間の約１００％実行した。実行動きのこの変化は、興味のある点を示す場合があるであろう。ユーザは、この点にズームインし、関連性のあるプロセスを調べ、拡大して、どのスレッドが実行していたのかを決定する。
【0071】
[0125] 特定の実施形態では、ブックマークが、ユーザが、グラフペインで興味のある情報に容易に戻ることを可能にする。図２８では、ブックマークＡ、Ｂ、Ｃ、及びＤが表示される。Ａ及びＣは、シャドーカーソルで示され、Ｂが選択をフックマークし、ＤがＴＩＭＥＭＡＣＨＩＮＥ（登録商標）カーソルをブックマークする。Ｃ及びＤのような青のレタリングを有するブックマークは、ＴＩＭＥＭＡＣＨＩＮＥ（登録商標）データと関連付けられる。ブックマークＩＤ（Ａ、Ｂ、Ｃ、及びＤ）は、グラフペインの上部に表示される。ブックマークは、ユーザがシステムの実行についての概念を共用できるようにするために特に役立つ。これは、ブックマークにメモが付けられるとき、特に当てはまる。
【0072】
[0126] 特定の実施形態では、ツールチップは、グラフペイン及び説明文内の項目についてより多くの情報を提供する（図２９を参照すること）。例えば、文字列変数の表示信号内でログポイント上をホバリングすると、記録された文字列が示される。スレッド表示信号の呼出しスタックグラフ領域内の関数の上でホバリングすると、関数が中で実行していたスレッド及びプロセスの名前だけではなく、関数の名前及び持続時間も示される。グラフペイン内で要約される表示信号データ上でホバリングすると、拡大された同じデータが示される（図３０Ａに示される例示的な実施形態を参照すること）。これらの方法は、ユーザがズームインすることを必要とせずに、ユーザが特定のイベントについての詳細な情報を迅速に見ることを可能にする。
【0073】
[0127] 特定の実施形態では、その記述テキストが複数の行にわたるイベントは、例えば改行（複数可）を表すために使用される「ｎ」等の特別なマーカーで、単一行として特定のコンテクストに表示される。これは、すべてのイベントの記述テキストの高さが統一されていることを確実にする。他の実施形態は、複数行テキストを示すことをサポートしてよい。代わりに、それらは、ユーザの必要性に基づいて、単一行と複数行のテキストを交互に切り替えてよい。特定の実施形態では、複数行テキストは、それがツールチップに表示されるときそれ自体レンダリングされる。しかしながら、ツールチップのコンテンツは、その表示サイズを制限するために修正される場合がある。
【0074】
[0128]履歴要約の方法及びシステム
[0129] 本発明の態様が解決する問題のうちの１つは、任意の数の任意の離間されたイベントがあるデータセットを迅速に視覚化する方法に関与する。好ましくは、これらのイベントは、任意のズームレベルで可視でなければならず、好ましくは、これらのイベントは、秒の部分でレンダリングされなければならない。しかしながら、分析されたデータは、好ましくは入力されたデータよりも実質的に多い記憶空間を使用してはならない。
[0129] 本発明の態様が解決する問題のうちの１つは、任意の数の任意の離間されたイベントがあるデータセットを迅速に視覚化する方法に関与する。好ましくは、これらのイベントは、任意のズームレベルで可視でなければならず、好ましくは、これらのイベントは、秒の部分でレンダリングされなければならない。しかしながら、分析されたデータは、好ましくは入力されたデータよりも実質的に多い記憶空間を使用してはならない。
【0075】
[0130] 高いレベルでは、本発明の態様に従ってこれらの問題を解決するための要約手法は、（「サマリレベル」として知られる）トレースイベントのシーケンスの複数のレベルの表現を事前に計算することを含む。各レベルは、開始時間及び終了時間を有し、その期間内のすべてのトレースイベントを表す（「サマリエントリ」として知られる）レコードを含む。サマリレベルは、サマリレベルの中のサマリエントリによって表される期間が、倍率分より大きい又はより小さいという点で互いに異なる。サマリエントリは、計算コストが安価である、及び／又は表示のためのピクセル実行単位表現に変換しやすいように設計される。この要約手法を適切に設計されたレンダリングエンジンと使用すると、任意の多数のトレースイベントの視覚化が加速化される。
【0076】
[0131] レンダリングエンジンは、これらのサマリレベル表現を表示画面上のグラフィック表示（レンダリングテキスト、色、等）に変換することを担う。また、レンダリングエンジンは、どのサマリレベル（複数可）を使用するのかを選ぶことも担い、それらのサマリレベル（複数可）が、レンダリングエンジンが見ているサマリレベルに正確に一致しないとき、次いでレンダリングエンジンは同じ要約技術のいくつかを使用して、最も近い既存のレベルから新しいサマリレベルを作成する。このプロセスは本明細書の他の箇所で説明され、「再要約」と呼ばれる。
【0077】
[0132] 再度記述されるように、特定の実施形態での本発明の態様の手法は、
[0133] （ａ）ある期間の１つ以上のターゲットプロセッサによる１つ以上のコンピュータプログラムの実行からトレースイベントの集合を任意選択で受け取ることと、
[0134] （ｂ）トレースイベントのシーケンスの複数のレベルの表現をサマリレベルに事前に計算することと、
[0135] （ｃ）１つ以上のコンピュータ可読記憶媒体にサマリレベルを記憶することと、
[0136] （ｄ）該トレースレベルの１つ以上のうちの選択された部分を表示する要求に応えて、サマリレベルからトレースイベントのシーケンスの事前に計算された表現の部分集合を取り出し、該部分集合を表示装置でレンダリングすること
であり、
[0137] （ｉ）どのサマリレベルから読み取るかは、他の箇所で説明されているが、これはサマリレベルから読み取るために必要なデータの量が、事前に計算された表現で表されるトレースイベントの数に関係しているので、手法の重要な部分である。
[0133] （ａ）ある期間の１つ以上のターゲットプロセッサによる１つ以上のコンピュータプログラムの実行からトレースイベントの集合を任意選択で受け取ることと、
[0134] （ｂ）トレースイベントのシーケンスの複数のレベルの表現をサマリレベルに事前に計算することと、
[0135] （ｃ）１つ以上のコンピュータ可読記憶媒体にサマリレベルを記憶することと、
[0136] （ｄ）該トレースレベルの１つ以上のうちの選択された部分を表示する要求に応えて、サマリレベルからトレースイベントのシーケンスの事前に計算された表現の部分集合を取り出し、該部分集合を表示装置でレンダリングすること
であり、
[0137] （ｉ）どのサマリレベルから読み取るかは、他の箇所で説明されているが、これはサマリレベルから読み取るために必要なデータの量が、事前に計算された表現で表されるトレースイベントの数に関係しているので、手法の重要な部分である。
【0078】
[0138] さらに、特定の実施形態では、事前に計算された複数のレベルの表現のそれぞれは、サマリレベルごとに異なる固定サイズの期間を含む。
【0079】
[0139] そして特定の実施形態では、表現を取り出すために使用されるサマリレベルは、その期間が、表示装置上でのピクセル実行単位の期間以下であるサマリレベルを選ぶことによって決定される。
【0080】
[0140] 本発明の態様は、特定の実施形態で少なくとも以下の７つの問題を解決する。
（１）レンダリングエンジンが、任意のズームレベルで任意の量のデータを迅速にレンダリングする方法を決定すること、
（２）イベントが発生していない時間の領域についての情報を記憶しない方法を決定すること、
（３）ほとんどイベントを有さないサマリレベルを作成することを回避する方法を決定すること、
（４）任意に小さい期間又は大きい期間をカバーするサマリレベルが、データセットがそれらを必要とする場合に作成できるように、サマリレベルを動的に（オンザフライで）構築する方法を決定すること、
（５）すべてのデータを最初に走査する又はデータを通る複数のパスを行うことなくこれを行う方法を決定すること、
（６）追加データを処理し、表示し続けながら、トレースデータの部分集合を表示する方法を決定すること、及び
（７）レンダリングエンジンが任意の時間の範囲をレンダリングするために実行する必要のあるシーク数を最小限に抑えながら、これをすべて行う方法を決定すること。
（１）レンダリングエンジンが、任意のズームレベルで任意の量のデータを迅速にレンダリングする方法を決定すること、
（２）イベントが発生していない時間の領域についての情報を記憶しない方法を決定すること、
（３）ほとんどイベントを有さないサマリレベルを作成することを回避する方法を決定すること、
（４）任意に小さい期間又は大きい期間をカバーするサマリレベルが、データセットがそれらを必要とする場合に作成できるように、サマリレベルを動的に（オンザフライで）構築する方法を決定すること、
（５）すべてのデータを最初に走査する又はデータを通る複数のパスを行うことなくこれを行う方法を決定すること、
（６）追加データを処理し、表示し続けながら、トレースデータの部分集合を表示する方法を決定すること、及び
（７）レンダリングエンジンが任意の時間の範囲をレンダリングするために実行する必要のあるシーク数を最小限に抑えながら、これをすべて行う方法を決定すること。
【0081】
[0141]例示的な出力ファイルの詳細な説明
[0142] レンダリングエンジンが信号を表示するために使用する基本的なデータは、ＨＶＳファイルに記憶され、ファイル信号と呼ばれる。表示信号とファイル信号との間に１対１の対応はない場合がある。例えば、レンダリングエンジンがスレッドのための呼出しスタックグラフを表示するために示す単一の表示信号は、複数のファイル信号から成る場合がある。
[0142] レンダリングエンジンが信号を表示するために使用する基本的なデータは、ＨＶＳファイルに記憶され、ファイル信号と呼ばれる。表示信号とファイル信号との間に１対１の対応はない場合がある。例えば、レンダリングエンジンがスレッドのための呼出しスタックグラフを表示するために示す単一の表示信号は、複数のファイル信号から成る場合がある。
【0082】
[0143] 例示的な本実施形態では、ターゲットから収集されるすべてのトレースイベントは、複数のファイル信号に編成され、単一のＨＶＳファイルに記憶される。ファイルは、それぞれが時間で並べ替えられたデータの系列である、複数のインタリーブされたストリームを使用する。ストリームとファイル信号との間には多対１の対応がある場合がある。いくつかのストリームは、ストリームごとに事前に割り振られたブロックを使用することによってディスク上に同時に書き込むことができ、各ストリームは、最小のオーバヘッドを有する別個のエンティティとして読み取ることができる。特定の実施形態では、各ストリームは、当業者に既知の技術に従って、及び本開示を考慮してＢ＋ツリーを使用し、実装される。本例示的な実施形態では、ファイルは、ともに受け取られるとき、複数のファイル信号を表す複数のＢ＋ツリーの集合体を含む。
【0083】
[0144] 特定の実施形態では、ヘッダは、各ストリームの種類及びサイズについての情報だけではなく、ファイルの中のすべてのストリームに対するポインタを記憶する。任意の数のファイル信号は、データセットごとに新しいストリームを作成することによって変換／要約プロセスの間の任意のときにファイルに加えることができる。データは、適切なデータストリームにアペンドすることによってファイルに加えることができる。ヘッダは、追加データを含むあらゆる以前に既存のストリームのサイズを更新するためだけではなく、新しいストリームに対するポインタを保持するためにも周期的に書き込まれる。新しいヘッダは、前のヘッダを上書きしない。代わりに、新しいヘッダはファイルの新しい場所に書き込まれる。新しいヘッダが書き込まれ、その点までに要約されたストリームのすべてのデータが書き込まれると、カレントヘッダに対するメタデータポインタは新しいヘッダを指すために更新される。
【0084】
[0145] メタデータポインタは、書き込まれた後に修正されるファイルの唯一の部分であるため、及びメタデータポインタは、小さく、アトミックに更新できるため、要約エンジンとレンダリングエンジンとの間のロッキング機構の必要性はない。
【0085】
[0146] ファイル内のストリームは並べ替えられた順序で記憶され、各ストリームは別々に読み取ることができるため、データ読取装置は特定の時間の範囲及び特定のストリームからデータの問い合わせを行うことができる。特定の実施形態での並べ替えられたデータの二分探索は、最小のオーバヘッドで範囲の境界を迅速に突き止めることを可能にする。さらに、特定の実施形態での二分探索は、これらのノードはその子のノード及びそれらが指すリーフノードの時間範囲を含むので、Ｂ＋ツリーノードのレベルで行われてもよい。
【0086】
[0147]例示的な要約システムの構成要素
[0148] サマライザは、本文書中のここで及び他の箇所で（記録された最後のイベントで開始する）時間で後方に要約することに関連して説明されているが、同じ手法は（記録された最初のイベントで開始する）前方へ要約することについても役立つことに留意されたい。後方手法は最初に最も最近のデータを示すため、該手法は、プログラムがブレイクポイントにどのようにして到達したのかを判断するような状況でより役立つ傾向がある。しかしながら、前方に要約することも役立つ場合がある。例えば、システムがライブで実行中であり、要約エンジンに新しいトレースデータを送信中である場合、前方へ要約することは、ユーザが、起きていることの要約されたバージョンを、それが発生するにつれて表示できることを意味する。当業者は、後方へ要約するプロセスを理解すると前方へ要約することに容易に変換できる。
[0148] サマライザは、本文書中のここで及び他の箇所で（記録された最後のイベントで開始する）時間で後方に要約することに関連して説明されているが、同じ手法は（記録された最初のイベントで開始する）前方へ要約することについても役立つことに留意されたい。後方手法は最初に最も最近のデータを示すため、該手法は、プログラムがブレイクポイントにどのようにして到達したのかを判断するような状況でより役立つ傾向がある。しかしながら、前方に要約することも役立つ場合がある。例えば、システムがライブで実行中であり、要約エンジンに新しいトレースデータを送信中である場合、前方へ要約することは、ユーザが、起きていることの要約されたバージョンを、それが発生するにつれて表示できることを意味する。当業者は、後方へ要約するプロセスを理解すると前方へ要約することに容易に変換できる。
【0087】
[0149] 上記に示した優位点の場合、特定の実施形態では、通常、前方への時間順で処理又は編成されるトレースイベントデータに対して後方要約を実行することが望ましい。例えば、ハードウェアトレースシステムの出力は、前方時間順で処理され、編成される。例示的な実施態様では、前方時間順で編成されたトレースイベントデータに対するトレースイベントデータに対する後方要約は、例えばログの終わり等のトレースログの後のときから小さなトレースイベントデータのチャンクを取り出し、そのチャンクを前方に処理して、そのチャンクの中に含まれるトレースイベントデータのリストを逆時間順で生成することによって区分的に実行されてよい。
【0088】
[0150] 以前のチャンクの前の時間に発生するトレースイベントデータの次のチャンクが取り出され、同様に処理される。時間で早期の追加のチャンクは、同様に取り出され、処理される。チャンクの境界は、チャンクが前方に復号されるほど十分な情報を含むように一般的に選ばれ、使用されている特定のトレースイベントデータシステムに応じて変わる場合がある。これは、例えば、後方に要約しているときに本発明の実施形態に対して、通常は時間的に前方に処理されるトレースイベントデータを発する、ハードウェアトレースシステム等のシステムを適応させるために役立つ。より一般的には、通常は時間で前方に処理されるトレースイベントデータは、この区分的に後方の方法を使用し、時間で後方に処理されてよい。
【0089】
[0151] 図３１Ａに示されるように、特定の実施形態は、例えばターゲットシステム等のトレースイベントジェネレータ（３１００）からデータを受け取る。このデータは、次いで必要な場合、時間別にトレースイベントを並べ替えることを含む場合があるトレースイベントプロセッサ（３１１０）によって処理され、処理されたトレースイベントの複数のサブストリーム（３１２０ａ、３１２０ｂ、．．．３１２０ｎ）に割り当てられる。特に断りのない限り、「トレースイベント」は、各実施態様の特定の要件に応じて、トレースイベントジェネレータ（３１００）の出力、又はトレースイベントプロセッサ（３１１０）の出力を指す場合がある。
【0090】
[0152] 各ストリームは、単一のファイル信号専用である。「ファイル信号」が、最終的に要約され、ファイルに記憶される関係するトレースイベントの集合体を指すことに留意されたい。ファイル信号は、元のデータの処理の結果として作成される、又は除外される場合がある。例えば、トレースイベントソースは、２つの変数の値を記録する可能性がある。処理後（３１１０）、例示的な実施形態は、独自のファイル信号として各変数を出力し、さらにそれぞれの合計である第３のファイル信号を出力する可能性がある。用語「トレースイベント」の使用が、これらの例では後処理されたトレースイベントを指し、通常は、これらの後処理されたトレースイベントの単一のファイル信号だけを指すことに留意されたい。しかしながら、説明される手法は、処理ステップがあるか否か、及び複数のファイル信号があるか否かに関わりなく適用する。
【0091】
[0153] 図３１Ｂにさらに示されるように、各トレースイベントは、次いで未処理ファイルストリーム（３１３０）に記憶できる未処理イベント（３１６０）に変換される。代わりに、特定の実施形態では、トレースイベントジェネレータ（図３１での３１００）の出力からのトレースイベントは、サマリレベルジェネレータ（図３１Ｂでの３１５０）への入力として直接的に使用されてよい。具体的な詳細は、実施態様の要件に基づいて変わるが、目標は、イベントのストリームをファイルストリーム（３１３０）に記憶するのが容易である形式に変換することである。例えば、特定の実施形態では、数値データは、イベントの時間及び値とパッケージ化される。しかしながら、文字列イベントは、完全文字列表現を指す文字列テーブルインデックスに変えられてよい。これは、未処理イベントを固定サイズで保つ。この文字列テーブル（３１４０）はそれ自体独自のファイルストリームに出力される。特定の実施形態では、未処理イベントを表示することは、これらのイベントが最初に、それらが未処理ファイルストリームで記憶される形式から人間が理解可能な表現に変換されることを必要とする。例えば、文字列イベントは、その文字列テーブルインデックスからテーブル内のそのインデックスで記憶される文字列に変換される。
【0092】
[0154] また、図３１Ｂは、未処理イベントが、１つ以上のサマリエントリを１つ以上のサマリレベル（３１４５）に任意選択で出力するサマリレベルジェネレータ（３１５０）に送り込まれることも示す。このプロセスのより詳細なバージョンは図３１Ｃに示され、図３１Ｄは、例示的な実施形態でのサマリレベルごとの特定のファイルストリームのコンテンツを示す。各サマリレベルは、トレースイベントの表現であり、特定のズームレベルで特定の時間の範囲のグラフィック表現の構築に合わせられる。例えば、レンダリングエンジンは、画面スペースの１０００のピクセル実行単位を使用し、１，０００秒から２，０００秒の時間範囲内に含まれる全イベントを示すタスクを課せられる場合がある。これは、各ピクセル実行単位が、その秒に相当する時間に含まれることになる、１秒に相当するトレースイベントを表すことを暗示する。この表示を作成するために、レンダリングエンジンは、他とともに要約エンジンによって作成された特定のサマリレベルを使用する。
【0093】
[0155] 他の箇所に説明されるように、サマリストリームは、未処理データのコピー、レンダリングエンジンに対する未処理ファイルストリームから追加データを読み取る命令（これらは、他の箇所では「未処理参照」と呼ばれる）、及び多くのトレースイベントを表す要約されたエントリを含むいくつかの種類のデータを含んでよい。
【0094】
[0156] 各サマリレベルは、時間順で記憶されたサマリエントリのシーケンスを含む。所与のサマリレベルの中の各サマリエントリは、多くても設定期間をカバーする。特定の実施形態では、複数のサマリレベルが使用され、そのそれぞれは、異なる時間の範囲に及ぶサマリエントリのシーケンスを含む。特定の実施形態では、任意の２つのサマリレベルによってカバーされる期間は、「倍率」と呼ばれる定数係数分、異なる。
【0095】
[0157] 特定の実施形態では、各サマリレベルは、データストリームを互いと無関係に問い合わせることができるように別々のストリームに記憶される。レンダリングエンジンは、次いでどのサマリレベルが適切であるのかを決定できる。レンダリングエンジンの特定の実施形態は、画面上の各ピクセル実行単位が表す時間のサイズに最も近いが、それ以下であるサマリレベルを使用し、それらはそのレベルで要約されたデータに問い合わせることができる。
【0096】
[0158] 特定の実施形態は、例えばトレースイベントが表すデータの型、又はデータの値等の実施態様の要件に基づいて個々のトレースイベントに（「シグナチャ」とも呼ばれる）１つ以上の「トレースイベントシグナチャ（複数可）」を生成する。特定の実施形態では、これらのトレースイベントシグナチャは、各実施態様の要件に応じて、以下の特徴を実際的な最大範囲まで示すように設計されるべきである。（１）トレースイベントシグナチャのサイズは、ファイル信号のあらゆるトレースイベントについて同じである（特に、通常、同じ種類のトレースイベントであるサブストリーム中のあらゆるトレースイベント、特定の実施形態は、トレースイベントごとに複数のトレースイベントシグナチャを生成してよい）、（２）シグナチャは、多大な計算又はメモリを必要とすることなく迅速に生成できる、（３）トレースイベントシグナチャは、異なる値を有する異なるトレースイベントのトレースイベントシグナチャとは異なっているという高い確率を有する。特定の実施形態は、トレースイベントシグナチャを、異なるトレースイベントシグナチャから区別可能であるという高い確率を有するグラフィック表現に変換する方法を有する。
【0097】
[0159] 各サマリエントリは、その時間範囲内で発生したすべてのトレースイベントの表現を含む。この表現は、上述されたトレースイベントシグナチャと区別するために、「シグナチャ」又は「サマリエントリシグナチャ」として知られる。レンダリングエンジンは、サマリエントリがカバーする時間の範囲を表すピクセル実行単位に含まれるピクセルを引き出すためにサマリエントリシグナチャを使用する。サマリエントリシグナチャは、各実施態様の要件に応じて、実際的な最大範囲まで以下の特徴を示すように設計されるべきである。（１）サマリエントリシグナチャのサイズは、それが表す要約されたトレースイベントの数に関係なく（つまり、独立しており）、所与のサマリレベルについて固定されている（同じトレースイベントサブストリームのための異なるサマリレベル、及び異なるトレースイベントサブストリームのためのファイル信号は、異なる固定サイズを使用してよい）。（２）サマリエントリシグナチャは、多大な計算を必要する、又はメモリに設定数を超えるトレースイベントを保つことなく迅速に計算できる。（３）サマリエントリシグナチャは、トレースイベントの異なる集合を表す別のシグナチャとは視覚的に異なっている高い確率を有するグラフィック表現に変換できる。
【0098】
[0160] さらに、種類に応じて、複数のトレースイベントシグナチャを１つのサマリエントリシグナチャにマージする方法が実施されてよい（特定の実施形態は、複数のサマリエントリシグナチャを１つのサマリエントリシグナチャにマージするための方法を実施してもよい）。また、特定の実施形態は、サマリエントリシグナチャをディスプレイにレンダリングする手法も実施する。
【0099】
[0161] 各特定の実施態様の要件に応じて、トレースイベントシグナチャを生成する多くの手法が達成されてよい。特定の実施形態は、例えばイベントの種類又はデータの値等のさまざまな要因に基づいて複数の異なるトレースイベント要約を生成する。いくつかの具体的な例は、以下を含むが、これに限定されるものではない。
（１）関数呼出しについての情報を含むファイル信号。トレースイベントシグナチャは、固定幅ビットフィールドの形式をとる。個々のトレースイベントのシグナチャの値は、１に設定された単一ビットを有するビットフィールドである。設定されるビットは、関数の名前、アドレス、又は他の識別マーカー（例えば、それがどのファイル、ライブラリ、又は他のグルーピングの一部であるのか）のハッシュによって決定される。このハッシングプロセスは、他のファイル信号種類でもシグナチャのために使用され、これ以降、「単一ビットハッシュ」と呼ばれる。ビットフィールドの幅は、同じファイル信号種類の全シグナチャ間で共有される。しかしながら、特定の実施形態では、ビットフィールドの幅は、ファイル信号種類に応じて異なる場合がある。固定幅は、異なる入力が同じシグナチャを生じさせる場合があるが、見込みは固定幅ビットフィールドのサイズに基づくであろうことを意味する。６４ビットフィールドの場合、それは６４のうちの１であるであろう。実施態様の要件に応じて、該６４ビットの例の場合、トレースイベントシグナチャの表示は、６４エントリカラーテーブルを調べるためにビットセットを使用して、トレースイベントを表示するときにどの色を使用するのかを決定できる。これは、同じシグナチャサイズを有すること、迅速なシグナチャ生成、及び２つの異なるトレースイベントが異なるトレースイベントシグナチャ及び色を有する可能性を高めることの３つすべての目標を達成する。
（２）文字列イベントについての情報を含むファイル信号。トレースイベントシグナチャは、文字列のコンテンツから計算された単一のビットハッシュである。あるいは、特定の実施形態は、その要件に応じて、文字列テーブルの中でのその位置、又は文字列がターゲットシステムメモリに記憶される等、文字列のなんらかの他の特性に従って文字列のシグナチャを計算してよい。各実施態様の要件に応じて、トレースイベントシグナチャの表示は、６４エントリカラーテーブルを調べるためにビットセットを使用して、トレースイベントを表示するときにどの色を使用するのかを決定できる。これは、同じシグナチャサイズを有すること、迅速なシグナチャ生成、及び２つの異なるトレースイベントが異なるトレースイベントシグナチャを有する可能性を高めるという３つすべてのトレースイベントシグナチャの目標を達成する。
（３）スレッドがどのプロセッサで実行したのかについての情報を含むファイル信号。シグナチャは、スレッドが実行したプロセッサの識別子の単一ビットハッシュである。実施態様の表示の要件に応じて、トレースイベントシグナチャの表示は、６４エントリカラーテーブルを調べるためにビットセットを使用して、トレースイベントを表示するときにどの色を使用するのかを決定できる。これは、同じシグナチャサイズを有すること、迅速なシグナチャ生成、及び２つの異なるトレースイベントが異なるトレースイベントシグナチャを有する可能性を高めるという３つすべてのトレースイベントシグナチャの目標を達成する。
（４）プロセッサがどのスレッドを実行したのかについての情報を含むファイル信号。シグナチャは、プロセッサが実行したスレッドの識別子の単一ビットハッシュである。実施態様の要件に応じて、トレースイベントシグナチャの表示は、６４エントリカラーテーブルを調べるためにビットセットを使用して、トレースイベントを表示するときにどの色を使用するのかを決定できる。これは、同じシグナチャサイズを有すること、迅速なシグナチャ生成、及び２つの異なるトレースイベントが異なるトレースイベントシグナチャを有する可能性を高めるという３つのすべてのトレースイベントシグナチャの目標を達成する。
（５）数値から成るファイル信号。特定の実施形態では、シグナチャは値自体の形をとる。これは、同じシグナチャサイズを有すること、迅速なシグナチャ生成、及び２つの異なるトレースイベントが異なるトレースイベントシグナチャを有する可能性を高めるという３つのすべてのトレースイベントシグナチャの目標を達成する。
（６）（例えば、プロセッサ上で実行中である、セマフォ上でブロックされている等）スレッドの実行状態の持続時間に関するイベントを含むファイル信号。特定の実施形態では、シグナチャは、スレッドが実行している間に経過した時計の目盛りの数のカウンタ（又はなんらかの別の実行の単位）の形をとる。特定の実施形態では、イベントの持続時間は、開始時刻から終了時刻を差し引くことによって決定できる。同じ手法は、シグナチャが、プロセッサがコードを実行していた間に経過したサイクル数を追跡する、プロセッサの実行状態にも適用できる。これは、同じシグナチャサイズを有すること（実施形態は、６４ビット整数に時間を記憶できるであろう）、迅速なシグナチャ生成、及び２つの異なるトレースイベントが、異なるトレースイベントシグナチャを有する可能性を高めるという３つすべてのトレースイベントシグナチャの目的を達成する。
（７）（例えば、プロセッサで実行中である、セマフォ上でブロックされている等）スレッドの実行状態に関するイベントを含むファイル信号。特定の実施形態では、シグナチャは、（例えば、列挙値又は状態の文字列名前等）その実行状態を表す値の形をとる。同じ手法は、プロセッサの実行状態にも適用できる。これは、同じシグナチャサイズを有すること（実施形態は、３２ビット整数に状態を記憶できるであろう）、迅速なシグナチャ生成（特定の実施形態は、実行状態を表すトレースイベントの値を記憶するであろう）、及び２つの異なるトレースイベントが、異なるトレースイベントシグナチャを有する可能性を高めるという３つすべてのトレースイベントシグナチャの目的を達成する。
（１）関数呼出しについての情報を含むファイル信号。トレースイベントシグナチャは、固定幅ビットフィールドの形式をとる。個々のトレースイベントのシグナチャの値は、１に設定された単一ビットを有するビットフィールドである。設定されるビットは、関数の名前、アドレス、又は他の識別マーカー（例えば、それがどのファイル、ライブラリ、又は他のグルーピングの一部であるのか）のハッシュによって決定される。このハッシングプロセスは、他のファイル信号種類でもシグナチャのために使用され、これ以降、「単一ビットハッシュ」と呼ばれる。ビットフィールドの幅は、同じファイル信号種類の全シグナチャ間で共有される。しかしながら、特定の実施形態では、ビットフィールドの幅は、ファイル信号種類に応じて異なる場合がある。固定幅は、異なる入力が同じシグナチャを生じさせる場合があるが、見込みは固定幅ビットフィールドのサイズに基づくであろうことを意味する。６４ビットフィールドの場合、それは６４のうちの１であるであろう。実施態様の要件に応じて、該６４ビットの例の場合、トレースイベントシグナチャの表示は、６４エントリカラーテーブルを調べるためにビットセットを使用して、トレースイベントを表示するときにどの色を使用するのかを決定できる。これは、同じシグナチャサイズを有すること、迅速なシグナチャ生成、及び２つの異なるトレースイベントが異なるトレースイベントシグナチャ及び色を有する可能性を高めることの３つすべての目標を達成する。
（２）文字列イベントについての情報を含むファイル信号。トレースイベントシグナチャは、文字列のコンテンツから計算された単一のビットハッシュである。あるいは、特定の実施形態は、その要件に応じて、文字列テーブルの中でのその位置、又は文字列がターゲットシステムメモリに記憶される等、文字列のなんらかの他の特性に従って文字列のシグナチャを計算してよい。各実施態様の要件に応じて、トレースイベントシグナチャの表示は、６４エントリカラーテーブルを調べるためにビットセットを使用して、トレースイベントを表示するときにどの色を使用するのかを決定できる。これは、同じシグナチャサイズを有すること、迅速なシグナチャ生成、及び２つの異なるトレースイベントが異なるトレースイベントシグナチャを有する可能性を高めるという３つすべてのトレースイベントシグナチャの目標を達成する。
（３）スレッドがどのプロセッサで実行したのかについての情報を含むファイル信号。シグナチャは、スレッドが実行したプロセッサの識別子の単一ビットハッシュである。実施態様の表示の要件に応じて、トレースイベントシグナチャの表示は、６４エントリカラーテーブルを調べるためにビットセットを使用して、トレースイベントを表示するときにどの色を使用するのかを決定できる。これは、同じシグナチャサイズを有すること、迅速なシグナチャ生成、及び２つの異なるトレースイベントが異なるトレースイベントシグナチャを有する可能性を高めるという３つすべてのトレースイベントシグナチャの目標を達成する。
（４）プロセッサがどのスレッドを実行したのかについての情報を含むファイル信号。シグナチャは、プロセッサが実行したスレッドの識別子の単一ビットハッシュである。実施態様の要件に応じて、トレースイベントシグナチャの表示は、６４エントリカラーテーブルを調べるためにビットセットを使用して、トレースイベントを表示するときにどの色を使用するのかを決定できる。これは、同じシグナチャサイズを有すること、迅速なシグナチャ生成、及び２つの異なるトレースイベントが異なるトレースイベントシグナチャを有する可能性を高めるという３つのすべてのトレースイベントシグナチャの目標を達成する。
（５）数値から成るファイル信号。特定の実施形態では、シグナチャは値自体の形をとる。これは、同じシグナチャサイズを有すること、迅速なシグナチャ生成、及び２つの異なるトレースイベントが異なるトレースイベントシグナチャを有する可能性を高めるという３つのすべてのトレースイベントシグナチャの目標を達成する。
（６）（例えば、プロセッサ上で実行中である、セマフォ上でブロックされている等）スレッドの実行状態の持続時間に関するイベントを含むファイル信号。特定の実施形態では、シグナチャは、スレッドが実行している間に経過した時計の目盛りの数のカウンタ（又はなんらかの別の実行の単位）の形をとる。特定の実施形態では、イベントの持続時間は、開始時刻から終了時刻を差し引くことによって決定できる。同じ手法は、シグナチャが、プロセッサがコードを実行していた間に経過したサイクル数を追跡する、プロセッサの実行状態にも適用できる。これは、同じシグナチャサイズを有すること（実施形態は、６４ビット整数に時間を記憶できるであろう）、迅速なシグナチャ生成、及び２つの異なるトレースイベントが、異なるトレースイベントシグナチャを有する可能性を高めるという３つすべてのトレースイベントシグナチャの目的を達成する。
（７）（例えば、プロセッサで実行中である、セマフォ上でブロックされている等）スレッドの実行状態に関するイベントを含むファイル信号。特定の実施形態では、シグナチャは、（例えば、列挙値又は状態の文字列名前等）その実行状態を表す値の形をとる。同じ手法は、プロセッサの実行状態にも適用できる。これは、同じシグナチャサイズを有すること（実施形態は、３２ビット整数に状態を記憶できるであろう）、迅速なシグナチャ生成（特定の実施形態は、実行状態を表すトレースイベントの値を記憶するであろう）、及び２つの異なるトレースイベントが、異なるトレースイベントシグナチャを有する可能性を高めるという３つすべてのトレースイベントシグナチャの目的を達成する。
【0100】
[0162] また、各特定の実施態様の要件に応じて、全種類のファイル信号は、ファイル信号に応じて規則で定義される色の形をとってもよい。例えば、（ａ）関数呼出しのためのファイル信号は、関数ごとに色を定めることができるであろう。（ｂ）警告及びエラーを表す文字列イベントのためのファイル信号は、（例えば、重大なエラーの場合赤、警告の場合黄色、及び一般的な通知の場合青等の）通知の重大度に基づいて色を定めることができるであろう。特定の実施形態は、ユーザの要件に基づいて（例えば、構成ファイルを通して）色表現を定めてよい。例えば、構成ファイルは、トレースイベント値からユーザ指定色へのマッピングを定めることができるであろう。これは、同じトレースイベントシグナチャサイズを有すること（実施形態は、２４ビット整数に色を記憶できるであろう）、迅速なシグナチャ生成（例えば、少なくとも構成ファイルマッピング等の、色関数に対するトレースイベント値が単純である実施形態の場合）、及び２つの異なるトレースイベントが異なるトレースイベントシグナチャを有する可能性を高めるという３つすべてのトレースイベントシグナチャの目標を達成する。後者の２つについて、それは使用される具体的な規則に依存する。一例に、値から色へのユーザ構成ファイルマッピングは、完了するのが早く、ユーザの要件に基づいて他とは異なるトレースイベントシグナチャを生成する。従って、例えば、ユーザが、エラーを警告と区別することに最も関心があり、エラーが赤として定められ、警告が黄色として定められている場合には、２つの異なるエラーは同じ色（赤）である場合があるが、ユーザはエラーと警告を容易に区別できるであろうし、これがユーザにとって重要である場合があることである。
【0101】
[0163] それぞれの特定の実施形態に応じて、トレースイベントシグナチャは、トレースイベントの値であってよい。これは、問題のトレースイベントがそれ自体固定サイズ（例えば、可変サイズの文字列と対照的に、３２ビットの整数）であるかどうかに応じて、固定サイズのトレースイベントシグナチャの目標を達成する場合もあれば、達成しない場合もある。それは、容易に計算可能であるという目標を達成する。定義によれば、トレースイベントシグナチャは、異なるトレースイベント値の場合異なる。
【0102】
[0164] 特定の実施形態では、ある種のファイル信号は、上記手法の組み合わせを使用してトレースイベントシグナチャを生成する。例えば、スレッドの場合、実行時間を追跡するためにはより下位のビットが使用されてよく、スレッドがどのプロセッサ上で実行したのかを表すためにはより上位のビットが使用されてよい。実施態様の要件に応じて、実施形態は、１つのシグナチャで複数のトレースイベントシグナチャタイプを表してよい。例えば、スレッドがその上で実行したプロセッサでの実行された時間のシグナチャは結合されて、シグナチャを構成しているトレースイベントシグナチャのサイズの合計サイズであるシグナチャを形成してよい。
【0103】
[0165] さらに、特定の実施形態では、ある種のトレースイベントは、それらのために生成されるトレースイベントシグナチャの種類ごとに１つ、複数のファイル信号を生成してよい。これは、トレースイベントのストリームを、それぞれが異なる種類のトレースイベントシグナチャを生成し、独自のトレースイベントストリームで要約される、すべてのトレースイベント（又は問題のサブストリームのすべてのトレースイベント）を含む複数のサブストリームに変えるのと実質的に同じである。
【0104】
[0166] サマリエントリのためのシグナチャを作成するために（つまり、サマリエントリシグナチャを作成するために）、そのサマリエントリによって表されるイベントのトレースイベントシグナチャを結合するための方法が必要とされる。特定の実施形態では、トレースイベントシグナチャをマージする方法（つまり、複数のトレースイベントシグナチャに基づいてサマリエントリシグナチャを作成する方法）は、制限なく、以下を含む。
（１）数値データのすべてのトレースイベントシグナチャの最小値及び最大値を採取し、サマリエントリシグナチャとしてこの最小値／最大値の対を出力すること。例えば、その値が５０、０、２５、１５、７５であるサマリエントリによって表されるトレースイベントのシーケンスの場合、トレースイベントシグナチャは値自体となり、サマリエントリシグナチャは０～７５となるであろう。これは、トレースイベントシグナチャのサイズの２倍であることによってサマリエントリシグナチャの最初の２つの目標を達成する（最小値のための目標、又は最大値のための目標）。これは、それぞれを順番に検査し、現在の最小値及び最大値だけをメモリに保持することによって、メモリにすべてのトレースイベントを保持することなく迅速に生成できる。視覚的に異なるという第３の目標は、トレースイベントが異なる最小値／最大値を有するときに達成される。多くの種類のデータセットでは、高いレベルで最小値／最大値を確かめることは、焦点をあてる領域を決定するために非常に有用であり、これが要約手法の目的を達成する。他のデータセットには、平均、中央値、モード、標準偏差、又は他の数値分析手法を確かめることが役立つ場合がある。特定の実施形態は、サマリエントリシグナチャに最小値／最大値及び平均値（又は他の数値分析）を含み、実施態様の要件に応じて、同じデータプロット上にオーバレイされる該追加情報を表示する。
（２）一連の任意の適切な規則に従ってシグナチャ値をランク付けすること。例えば、例示的な実施態様は、最大ランク値及び／又は最小ランク値を識別してよく、次いで最大ランク値及び／又は最小ランク値は、新しいシグナチャを決定するために使用されてよい。これは少なくとも、いくつかのトレースイベントが他よりも高いレベルのビューから示すためにより重要である、データのシグナチャにとって有用である。例えば、特定の実施態様では、エラーメッセージは、情報メッセージよりも高くランク付けされるであろう警告メッセージよりも高くランク付けられるであろう。この例では、一方がエラーメッセージを表し、他方が警告を表す２つのトレースイベントシグナチャをマージすると、エラーメッセージを表す新しいサマリエントリシグナチャが生じるであろう（従って、サマリエントリシグナチャは、警告についての情報を含まない）。特定の実施形態では、これは、（ａ）（それ自体が固定サイズである）トレースイベントシグナチャと同じサイズであることによって固定サイズを有すること、（ｂ）各トレースイベントシグナチャが処理されるので、現在の最善の一致だけをメモリに保持する必要があるため、計算するのが容易であること、（ｃ）表示が、異なる重大度である少なくとも他のサマリエントリシグナチャと区別可能であること（例えば、特定の実施形態で、２つの異なるエラーが区別可能ではない場合があるが、エラーは警告から容易に区別可能である）によって、サマリエントリシグナチャの３つの目標を達成する。
（３）トレースイベントシグナチャ値をサマリエントリシグナチャにブレンドすること。これは少なくとも、色であるそれらのシグナチャにとって有用である。トレースイベントシグナチャからサマリエントリシグナチャにブレンドすることは、当業者が精通しているであろう混合手法のいずれかを使用できるであろう。特定の実施形態では、ブレンドすることは、実施態様の要件に応じて、異なる色空間、色表現、又は色を表すために使用されるフィールドのサイズへ変換できるであろう。特定の実施形態では、これは、以下ことによって、サマリエントリシグナチャの３つの目標を達成する。（ａ）サマリエントリシグナチャは色にすぎないため、シグナチャのサイズは、表されるイベントの数に関係しておらず、例えば２４ビット値又は３２ビット値で表すことができるであろう、（ｂ）特定の実施形態が、当該技術分野で既知の手法を使用し、色をブレンドする問題を解決する。例えば、色は、赤、青、及び緑を表す３つの８ビット部分から構成された２４ビット値で表すことができる。トレースイベントシグナチャを要約することは、トレースイベントシグナチャのそれぞれの各８ビット成分を別々に３つの６４ビット蓄積値（赤の成分、青の成分、及び緑の成分にそれぞれ１つ）に合計することによって行われる。次いで、６４ビット蓄積値は、サマリエントリによって表されるトレースイベントの数で除算することができ、各８ビットの混合された／平均された色成分は、２４ビットのカラーサマリエントリシグナチャの適切な部分集合の中に記憶される。実際には、例外的に多数のイベントを除き、これは６４ビットアキュムレータをオーバフローさせない。これは、各色が多くても２５５の値を有することができるためである。従って、６４ビット値は、オーバフローする前に少なくとも（２＾６４）／２５６トレースイベント、つまり６５５３６兆のトレースイベントである２＾５６を記憶できる。実施形態がより多くのイベントを表すことを必要とするならば、実施形態は、アキュムレータを第２の６４ビット整数等に連鎖するであろう。最終的に、実施形態は、宇宙にある原子よりも多いトレースイベントを表すことができ、これは実際には、メモリにすべての又はほんのわずかなトレースイベントも保持する必要なく、制限がないことを意味する。（ｃ）グラフ表現は、トレースイベント内の色が、２つのサマリエントリによって表される、トレースイベントの２つの集合の間で異なる傾向があるときに区別可能である。従って、例えば、１つのサマリの中の大部分のイベントが赤であり、異なるサマリエントリの大部分が青である場合、次いで各サマリで平均化される色は赤及び青となり、互いに区別可能となる。色を単に平均化することを超えたブレンドするための他の手法があることに留意されたい。例えば、特定の実施形態は、基本的なトレースイベントシグナチャでどの色が使用されるのかを決定し、次いでそれらの色だけをブレンドする。これは、所与の色が、サマリエントリによってカバーされるトレースイベントシグナチャに何回存在するのかに依存しない色のブレンドを生じさせる。
（４）各シグナチャの中でのトレースイベントの相対的な発生頻度に従ってトレースイベントシグナチャ値をブレンドすること。それは他の状況にも当てはまるが、これは、持続時間を有さないトレースイベントを表す色であるそれらのシグナチャにとって特に有用である。例えば、サマリエントリが１１０のトレースイベントを表し、そのうちの１００が青のシグナチャを有し、１０が赤のシグナチャを有する場合、結果として生じるサマリエントリシグナチャ色値は、１０部分の青（１０ ｐaｒｔｓ ｂｌuｅ）及び１部分の赤（１ ｐａｒｔ ｒｅｄ）を有するであろう。これがどのようにしてサマリエントリシグナチャの目標を達成するのか、及びこの手法の例の実施形態は、上記に概略されている。
（５）各シグナチャの中でのトレースイベントの相対的な発生の持続時間に従ってシグナチャ値をブレンドすること。それは他の状況にも当てはまるが、これは、持続時間を有するトレースイベントを表す色であるそれらのシグナチャにとって特に有用である。例えば、その一方が緑であり、５秒間アクティブであったトレースイベントを有し、その一方が黄色であり、１秒間アクティブであったトレースイベントを有する２つのトレースイベントシグナチャがある場合、シグナチャがマージされるとき、結果として生じる色は、５部分の緑及び１部分の黄色を有するであろう。
（６）すべてのトレースイベントシグナチャのビット論理和を実行すること。それは他の状況にも当てはまるが、これは、単一のビットハッシュであるそれらのトレースイベントシグナチャにとって特に有用である。文字列トレースイベントのための例の実施形態は、他の箇所で説明されたように、文字列を、トレースイベントシグナチャとして使用される１つのビットハッシュにハッシュするであろう。サマリエントリによって表されるトレースイベントシグナチャは次いで互いにＯＲされ、サマリエントリシグナチャを生じさせるであろう。次いで、そのサマリエントリシグナチャは、画面にレンダリングされるであろう。特定の実施形態は、サマリエントリシグナチャを、シグナチャ内の各ビットを色にマッピングし、次いで表示で使用するための最終的な色を生成するためにシグナチャ内で設定されたビットの色のすべてをブレンドすることによって決定される色として表示する。特定の実施形態では、これは、（ａ）（それ自体固定サイズである）トレースイベントシグナチャと同じサイズであることによって固定サイズを有すること、（ｂ）各トレースイベントシグナチャが処理されるので、蓄積されたビット論理和結果だけをメモリに保持する必要があるため、計算するのが容易であること、（ｃ）シグナチャがどのビットが設定されている、又は設定されていないのかを示すようにレンダリングされるとき、表示が、異なるビット論理和結果を有するトレースイベントを含む少なくとも他のサマリエントリシグナチャから区別可能であることによって、サマリエントリシグナチャの３つの目標を達成する。レンダリング手法については、以下を参照すること。
（７）基本的なシグナチャ値を合計すること。それは他の状況にも当てはまるが、これは、合計実行サイクル（又は他の実行の単位）及び他の蓄積値を記憶するそれらのシグナチャにとって特に有用である。特定の実施形態は、トレースイベントシグナチャの部分集合を合計するにすぎない場合がある。例えば、サイクルのスレッドの実行状態を表すトレースイベントをマージするとき、コードの実行を表すトレースイベントだけを合計できるであろう。これは、スレッドが、サマリエントリの期間中どれほど長く実行していたのかを表していたサマリエントリシグナチャを生じさせるであろう。スレッドが実行しなかった（例えば、スレッドが割り込まれた、セマフォ上でブロックされた、完了するためにシステムコールを待機していた等）ときは、含まれないであろう。スレッドがサマリエントリの期間中に実行しなかった場合、次いでサマリエントリシグナチャはゼロになるであろう。特定の実施形態では、これは、（ａ）（結果がオーバフローするのを妨げるために、サマリエントリシグナチャがそこから合計されるトレースイベントシグナチャよりも大きいサマリエントリシグナチャに記憶される場合がある）合計されたシグナチャ値を記憶することによって固定サイズを有すること、（ｂ）各トレースイベントシグナチャが処理されるので、現在の合計だけをメモリに保持するする必要があるため、計算が容易であること、（ｃ）表示が少なくとも、トレースイベントシグナチャの異なる集合の合計が異なるそれらの場合にだけ区別可能であることによってサマリエントリシグナチャの３つの目標を達成する。
（８）上記手法の組合せ。例えば、スレッドシグナチャが、プロセッサをハッシュすることによって作られる場合、スレッドは上位ビットで実行し、下位ビットは実行時間を記録し、上位ビットはビットＯＲされ、下位ビットは合計されるであろう。あるいは、特定の実施形態は、サマリエントリシグナチャを、単一のシグナチャ値のそれらの手法のすべてを表す新しいサマリエントリシグナチャの中に生成するための複数の手法を記憶できる。例えば、サマリエントリシグナチャの第１の６４ビットは、基本シグナチャ値の合計であり、第２の６４ビットは、１つのビットハッシュのビット論理和であるだろう。他の手法が当業者に明らかになるであろう。
（１）数値データのすべてのトレースイベントシグナチャの最小値及び最大値を採取し、サマリエントリシグナチャとしてこの最小値／最大値の対を出力すること。例えば、その値が５０、０、２５、１５、７５であるサマリエントリによって表されるトレースイベントのシーケンスの場合、トレースイベントシグナチャは値自体となり、サマリエントリシグナチャは０～７５となるであろう。これは、トレースイベントシグナチャのサイズの２倍であることによってサマリエントリシグナチャの最初の２つの目標を達成する（最小値のための目標、又は最大値のための目標）。これは、それぞれを順番に検査し、現在の最小値及び最大値だけをメモリに保持することによって、メモリにすべてのトレースイベントを保持することなく迅速に生成できる。視覚的に異なるという第３の目標は、トレースイベントが異なる最小値／最大値を有するときに達成される。多くの種類のデータセットでは、高いレベルで最小値／最大値を確かめることは、焦点をあてる領域を決定するために非常に有用であり、これが要約手法の目的を達成する。他のデータセットには、平均、中央値、モード、標準偏差、又は他の数値分析手法を確かめることが役立つ場合がある。特定の実施形態は、サマリエントリシグナチャに最小値／最大値及び平均値（又は他の数値分析）を含み、実施態様の要件に応じて、同じデータプロット上にオーバレイされる該追加情報を表示する。
（２）一連の任意の適切な規則に従ってシグナチャ値をランク付けすること。例えば、例示的な実施態様は、最大ランク値及び／又は最小ランク値を識別してよく、次いで最大ランク値及び／又は最小ランク値は、新しいシグナチャを決定するために使用されてよい。これは少なくとも、いくつかのトレースイベントが他よりも高いレベルのビューから示すためにより重要である、データのシグナチャにとって有用である。例えば、特定の実施態様では、エラーメッセージは、情報メッセージよりも高くランク付けされるであろう警告メッセージよりも高くランク付けられるであろう。この例では、一方がエラーメッセージを表し、他方が警告を表す２つのトレースイベントシグナチャをマージすると、エラーメッセージを表す新しいサマリエントリシグナチャが生じるであろう（従って、サマリエントリシグナチャは、警告についての情報を含まない）。特定の実施形態では、これは、（ａ）（それ自体が固定サイズである）トレースイベントシグナチャと同じサイズであることによって固定サイズを有すること、（ｂ）各トレースイベントシグナチャが処理されるので、現在の最善の一致だけをメモリに保持する必要があるため、計算するのが容易であること、（ｃ）表示が、異なる重大度である少なくとも他のサマリエントリシグナチャと区別可能であること（例えば、特定の実施形態で、２つの異なるエラーが区別可能ではない場合があるが、エラーは警告から容易に区別可能である）によって、サマリエントリシグナチャの３つの目標を達成する。
（３）トレースイベントシグナチャ値をサマリエントリシグナチャにブレンドすること。これは少なくとも、色であるそれらのシグナチャにとって有用である。トレースイベントシグナチャからサマリエントリシグナチャにブレンドすることは、当業者が精通しているであろう混合手法のいずれかを使用できるであろう。特定の実施形態では、ブレンドすることは、実施態様の要件に応じて、異なる色空間、色表現、又は色を表すために使用されるフィールドのサイズへ変換できるであろう。特定の実施形態では、これは、以下ことによって、サマリエントリシグナチャの３つの目標を達成する。（ａ）サマリエントリシグナチャは色にすぎないため、シグナチャのサイズは、表されるイベントの数に関係しておらず、例えば２４ビット値又は３２ビット値で表すことができるであろう、（ｂ）特定の実施形態が、当該技術分野で既知の手法を使用し、色をブレンドする問題を解決する。例えば、色は、赤、青、及び緑を表す３つの８ビット部分から構成された２４ビット値で表すことができる。トレースイベントシグナチャを要約することは、トレースイベントシグナチャのそれぞれの各８ビット成分を別々に３つの６４ビット蓄積値（赤の成分、青の成分、及び緑の成分にそれぞれ１つ）に合計することによって行われる。次いで、６４ビット蓄積値は、サマリエントリによって表されるトレースイベントの数で除算することができ、各８ビットの混合された／平均された色成分は、２４ビットのカラーサマリエントリシグナチャの適切な部分集合の中に記憶される。実際には、例外的に多数のイベントを除き、これは６４ビットアキュムレータをオーバフローさせない。これは、各色が多くても２５５の値を有することができるためである。従って、６４ビット値は、オーバフローする前に少なくとも（２＾６４）／２５６トレースイベント、つまり６５５３６兆のトレースイベントである２＾５６を記憶できる。実施形態がより多くのイベントを表すことを必要とするならば、実施形態は、アキュムレータを第２の６４ビット整数等に連鎖するであろう。最終的に、実施形態は、宇宙にある原子よりも多いトレースイベントを表すことができ、これは実際には、メモリにすべての又はほんのわずかなトレースイベントも保持する必要なく、制限がないことを意味する。（ｃ）グラフ表現は、トレースイベント内の色が、２つのサマリエントリによって表される、トレースイベントの２つの集合の間で異なる傾向があるときに区別可能である。従って、例えば、１つのサマリの中の大部分のイベントが赤であり、異なるサマリエントリの大部分が青である場合、次いで各サマリで平均化される色は赤及び青となり、互いに区別可能となる。色を単に平均化することを超えたブレンドするための他の手法があることに留意されたい。例えば、特定の実施形態は、基本的なトレースイベントシグナチャでどの色が使用されるのかを決定し、次いでそれらの色だけをブレンドする。これは、所与の色が、サマリエントリによってカバーされるトレースイベントシグナチャに何回存在するのかに依存しない色のブレンドを生じさせる。
（４）各シグナチャの中でのトレースイベントの相対的な発生頻度に従ってトレースイベントシグナチャ値をブレンドすること。それは他の状況にも当てはまるが、これは、持続時間を有さないトレースイベントを表す色であるそれらのシグナチャにとって特に有用である。例えば、サマリエントリが１１０のトレースイベントを表し、そのうちの１００が青のシグナチャを有し、１０が赤のシグナチャを有する場合、結果として生じるサマリエントリシグナチャ色値は、１０部分の青（１０ ｐaｒｔｓ ｂｌuｅ）及び１部分の赤（１ ｐａｒｔ ｒｅｄ）を有するであろう。これがどのようにしてサマリエントリシグナチャの目標を達成するのか、及びこの手法の例の実施形態は、上記に概略されている。
（５）各シグナチャの中でのトレースイベントの相対的な発生の持続時間に従ってシグナチャ値をブレンドすること。それは他の状況にも当てはまるが、これは、持続時間を有するトレースイベントを表す色であるそれらのシグナチャにとって特に有用である。例えば、その一方が緑であり、５秒間アクティブであったトレースイベントを有し、その一方が黄色であり、１秒間アクティブであったトレースイベントを有する２つのトレースイベントシグナチャがある場合、シグナチャがマージされるとき、結果として生じる色は、５部分の緑及び１部分の黄色を有するであろう。
（６）すべてのトレースイベントシグナチャのビット論理和を実行すること。それは他の状況にも当てはまるが、これは、単一のビットハッシュであるそれらのトレースイベントシグナチャにとって特に有用である。文字列トレースイベントのための例の実施形態は、他の箇所で説明されたように、文字列を、トレースイベントシグナチャとして使用される１つのビットハッシュにハッシュするであろう。サマリエントリによって表されるトレースイベントシグナチャは次いで互いにＯＲされ、サマリエントリシグナチャを生じさせるであろう。次いで、そのサマリエントリシグナチャは、画面にレンダリングされるであろう。特定の実施形態は、サマリエントリシグナチャを、シグナチャ内の各ビットを色にマッピングし、次いで表示で使用するための最終的な色を生成するためにシグナチャ内で設定されたビットの色のすべてをブレンドすることによって決定される色として表示する。特定の実施形態では、これは、（ａ）（それ自体固定サイズである）トレースイベントシグナチャと同じサイズであることによって固定サイズを有すること、（ｂ）各トレースイベントシグナチャが処理されるので、蓄積されたビット論理和結果だけをメモリに保持する必要があるため、計算するのが容易であること、（ｃ）シグナチャがどのビットが設定されている、又は設定されていないのかを示すようにレンダリングされるとき、表示が、異なるビット論理和結果を有するトレースイベントを含む少なくとも他のサマリエントリシグナチャから区別可能であることによって、サマリエントリシグナチャの３つの目標を達成する。レンダリング手法については、以下を参照すること。
（７）基本的なシグナチャ値を合計すること。それは他の状況にも当てはまるが、これは、合計実行サイクル（又は他の実行の単位）及び他の蓄積値を記憶するそれらのシグナチャにとって特に有用である。特定の実施形態は、トレースイベントシグナチャの部分集合を合計するにすぎない場合がある。例えば、サイクルのスレッドの実行状態を表すトレースイベントをマージするとき、コードの実行を表すトレースイベントだけを合計できるであろう。これは、スレッドが、サマリエントリの期間中どれほど長く実行していたのかを表していたサマリエントリシグナチャを生じさせるであろう。スレッドが実行しなかった（例えば、スレッドが割り込まれた、セマフォ上でブロックされた、完了するためにシステムコールを待機していた等）ときは、含まれないであろう。スレッドがサマリエントリの期間中に実行しなかった場合、次いでサマリエントリシグナチャはゼロになるであろう。特定の実施形態では、これは、（ａ）（結果がオーバフローするのを妨げるために、サマリエントリシグナチャがそこから合計されるトレースイベントシグナチャよりも大きいサマリエントリシグナチャに記憶される場合がある）合計されたシグナチャ値を記憶することによって固定サイズを有すること、（ｂ）各トレースイベントシグナチャが処理されるので、現在の合計だけをメモリに保持するする必要があるため、計算が容易であること、（ｃ）表示が少なくとも、トレースイベントシグナチャの異なる集合の合計が異なるそれらの場合にだけ区別可能であることによってサマリエントリシグナチャの３つの目標を達成する。
（８）上記手法の組合せ。例えば、スレッドシグナチャが、プロセッサをハッシュすることによって作られる場合、スレッドは上位ビットで実行し、下位ビットは実行時間を記録し、上位ビットはビットＯＲされ、下位ビットは合計されるであろう。あるいは、特定の実施形態は、サマリエントリシグナチャを、単一のシグナチャ値のそれらの手法のすべてを表す新しいサマリエントリシグナチャの中に生成するための複数の手法を記憶できる。例えば、サマリエントリシグナチャの第１の６４ビットは、基本シグナチャ値の合計であり、第２の６４ビットは、１つのビットハッシュのビット論理和であるだろう。他の手法が当業者に明らかになるであろう。
【0105】
[0167] 特定の実施形態は、複数のサマリエントリシグナチャを新しいサマリエントリシグナチャにマージできる。例えば、最小値から最大値を表し、第１のサマリエントリシグナチャが０～７５であり、第２が５０～１００であるサマリエントリシグナチャの場合、次いでこれらの２つをマージすると、０～１００である新しいサマリエントリが生じるであろう。複数のトレースイベントシグナチャをサマリエントリシグナチャにマージするための多くの手法は、当業者が容易に理解し得るように、複数のサマリイベントシグナチャをサマリエントリシグナチャにマージすることに適用できる。
【0106】
[0168] サマリシグナチャを表示するために、サマリエントリを画像に変える（つまり、画面上で表示される）ための方法が必要とされる。特定の実施形態では、シグナチャをレンダリングする方法は以下を含む。
（１）データプロットの高い点が最大値であり、低い点が最小値である、最小値／最大値データを追跡するシグナチャをプロットすること。最小値と最大値との間の空間は、他のデータ値が該２つの点の間に存在し得ることを示すために充填できる。例えば平均等の追加の値がサマリエントリシグナチャに含まれる場合、追加の値も描かれる場合がある。
（２）実行時間（又は他の実行の単位）を（例えば、スレッド又はプロセッサのための）サマリ領域の中で太いバーとして追跡するシグナチャをレンダリングすること。バーは、サマリエントリの期間中に経過した総数に対する、実行中に経過した時間の量（又は他の実行の単位）に比例して記入される。列の中の多くのシグナチャが並んでレンダリングされるとき、これは、負荷グラフとしても知られる、実行に費やされた時間を示すグラフとして表示する。
（３）異なるプロセッサを表すために使用される色をブレンドすることによって、スレッドがどのプロセッサで実行していたのかを追跡するシグナチャの色をレンダリングすること。この手法では、各ビットセットは色を表し、複数のビットが設定されるとき、出力される色はそれらの色のブレンドである。さらに、特定の実施形態は、考えられる数のプロセッサに基づいて色の間の視距離を最大化するために色を特定のビットに割り当てる。従って、例えば４台のプロセッサを有するシステムでは、異なる色は容易に区別できる。プロセッサがどのスレッドを実行しているのかを追跡するシグナチャの場合、類似する手法をとることができる。
（４）実行された異なる関数を表すために使用される色をブレンドすることによって１ビットハッシュで関数呼出しを追跡するシグナチャの色をレンダリングすること。この手法では、各ビットセットは色を表し、複数のビットが設定されるとき、出力される色はそれらの色のブレンドである。
（５）サマリエントリに存在する文字列値に割り当てられた色をブレンドすることによって１ビットハッシュで文字列を追跡するシグナチャの色をレンダリングすること。この手法では、各ビットセットは色を表し、複数のビットが設定されるとき、出力される色はそれらの色のブレンドである。
（６）上記手法の組合せ。例えば、どのプロセッサが上位ビットで実行しているのか、及び下位ビットで実行されるサイクルの数を記録する場合、上部ビットは全体的な色を決定し、下位ビットはバーの太さを決定する。
（１）データプロットの高い点が最大値であり、低い点が最小値である、最小値／最大値データを追跡するシグナチャをプロットすること。最小値と最大値との間の空間は、他のデータ値が該２つの点の間に存在し得ることを示すために充填できる。例えば平均等の追加の値がサマリエントリシグナチャに含まれる場合、追加の値も描かれる場合がある。
（２）実行時間（又は他の実行の単位）を（例えば、スレッド又はプロセッサのための）サマリ領域の中で太いバーとして追跡するシグナチャをレンダリングすること。バーは、サマリエントリの期間中に経過した総数に対する、実行中に経過した時間の量（又は他の実行の単位）に比例して記入される。列の中の多くのシグナチャが並んでレンダリングされるとき、これは、負荷グラフとしても知られる、実行に費やされた時間を示すグラフとして表示する。
（３）異なるプロセッサを表すために使用される色をブレンドすることによって、スレッドがどのプロセッサで実行していたのかを追跡するシグナチャの色をレンダリングすること。この手法では、各ビットセットは色を表し、複数のビットが設定されるとき、出力される色はそれらの色のブレンドである。さらに、特定の実施形態は、考えられる数のプロセッサに基づいて色の間の視距離を最大化するために色を特定のビットに割り当てる。従って、例えば４台のプロセッサを有するシステムでは、異なる色は容易に区別できる。プロセッサがどのスレッドを実行しているのかを追跡するシグナチャの場合、類似する手法をとることができる。
（４）実行された異なる関数を表すために使用される色をブレンドすることによって１ビットハッシュで関数呼出しを追跡するシグナチャの色をレンダリングすること。この手法では、各ビットセットは色を表し、複数のビットが設定されるとき、出力される色はそれらの色のブレンドである。
（５）サマリエントリに存在する文字列値に割り当てられた色をブレンドすることによって１ビットハッシュで文字列を追跡するシグナチャの色をレンダリングすること。この手法では、各ビットセットは色を表し、複数のビットが設定されるとき、出力される色はそれらの色のブレンドである。
（６）上記手法の組合せ。例えば、どのプロセッサが上位ビットで実行しているのか、及び下位ビットで実行されるサイクルの数を記録する場合、上部ビットは全体的な色を決定し、下位ビットはバーの太さを決定する。
【0107】
[0169] 特定の実施形態は、互いの上部に積層される一連のファイル信号として呼出しスタックブラフをレンダリングする。特定の実施形態は、より深いレベルをレンダリングする前に呼出しスタックグラフのより浅いレベルをレンダリングする。例えば、典型的なＣ／Ｃ＋＋プログラムでは、最も浅い呼出しスタックレベルは「主要な」関数である。この手法は、レンダリングエンジンが、それが呼出し情報がない点に達するとき、より深い呼出しスタックレベルのためのファイル信号データを検索するのを停止できるようにする。これは、イベントログにおける特定のズームレベル及び位置を所与として、空の呼出しスタックレベルのための作業を行う必要性を最適化により除去する。
【0108】
[0170] さらに、トレースイベントの分析が進行するにつれ、呼出しスタックレベルを発見し、加えることができる。より深い呼出しスタックレベルにより、より多くのファイル信号が既存のファイル信号の下方で加えられる。しかしながら、より浅いレベルも、既存のファイル信号を超えて加えることができる。これは、要約エンジンが前方又は後方に要約している間に発生する場合がある。例えば、メインの関数を含まないトレースデータが終了する状態で、Ｃ／Ｃ＋＋関数を後方に要約する実施形態は、関数の入口のトレースイベントに達するまで呼出しスタックグラフにメインを含まない場合がある。結果として、要約エンジンは、それが、メインのために呼出しスタックレベル（及び関連付けられたファイル信号）を作成する必要があることを知らない。しかしながら、要約エンジンは後方に要約し続けるにつれ、要約エンジンは、メインが入力されたことを示すトレースイベントに遭遇する場合がある。この点で、要約エンジンは、メインのためのスタックレベルを表すファイル信号を作成できる。特定の実施形態は、その要件に応じて、トレースログの終わり（又は開始）のための呼出しスタック状態を記憶してよい。これは、呼出しスタックの終了（又は、前方に要約している場合、開始）状態で呼出しスタックグラフファイル信号を初期化するために使用できる。このようにして、呼出しスタックグラフは、呼出しスタックの関数のいくつかが関連付けられた入口トレースイベント又は出口トレースイベントを有していなくても、終了する（又は、前方に進む場合開始する）呼出しスタック全体を表示できる。
【0109】
[0171] レンダリングエンジンが、一瞬を超える時間（例えば、その両方とも持続時間を有する状態又は関数呼出しを表すエントリ）を表すエントリを示すことを望むファイル信号の場合、特定の実施形態は、ファイルストリームの隣接するサマリエントリが連続的な時間の範囲を表さないとき、サマリエントリ間の未処理イベントを含む。これはレンダリングエンジンが、未処理ファイルストリームからデータを読み出すことなく、非連続サマリエントリ間で何を表示するのか決定できるようにする。例えば、図３２では、最終的なレンダリング表示が、要約されたイベント（３２００）を表す１ピクセル実行単位を示し、次に、状態が真（３２１０）であるときの期間を表す多くのピクセル実行単位が続き、次に再度、要約されたイベント（３２００）を表す１ピクセル実行単位を示す。サマリストリーム（３２３０）のコンテンツは、サマリエントリ（３２４０）、サマリエントリ間の期間を表す未処理イベント（３２５０）、及び他のサマリエントリ（３２６０）から成る。これが、表示をレンダリングするために必要とされるすべての情報である。３２７０で示されるように、サマリストリームが未処理エントリを含まなかった場合、レンダリングエンジンは、２つの非連続要約済みエントリ（３２８０、３２９０）間に（もしあれば）どのイベントを表示するのかを決定するために、ファイル信号の未処理ストリームから未処理イベントを見つけ出し、読み取る必要があるであろう。これは、少なくとも１つの追加ファイルシーク及び読取りを必要とするであろう。（サマリエントリ間の未処理イベントを含む）この最適化が、要約された期間内にほとんどイベントがないとき、サマリストリームにインラインで要約されていない未処理イベントを含む、他の箇所に説明される、最適化とは異なることに留意されたい。ここで説明される最適化を用いると、未処理イベントは、サマリエントリを開始する（終了する）最後の（又は最初の）イベントである。レンダリングエンジンは、イベント開始（又は終了）時間が、サマリエントリによって表される期間内に含まれるかどうかを判断することによって２つの最適化を区別する。
【0110】
[0172] 特定の実施形態では、持続時間を有するイベントは、それらが状態「への遷移」を表すのか、状態「からの遷移」を表すのか、それとも状態の開始又は終わりを表すのかを指定する必要もある。例えば、図３２では、未処理イベント３２５０は、イベントへの遷移である。それは、サマリエントリ３２６０に含まれる時間内の最後のイベントを表す。時間内の次のサマリエントリ―３２４０―は、９９の開始時間を有し、従って未処理イベント３２５０への遷移は、時間２から時間９９まで、状態が「なんらかの状態」であったことを示す。未処理イベントが代わりにイベントからの遷移であり、それが同じ状態情報を記録していた場合、それは、３２９５に示されるように、９９の終了時間を有するであろう。イベントへの遷移が使用されるのか、それともイベントからの遷移が使用されるのかは、サマライザに入力されるトレースイベントの形式に依存する。
【0111】
[0173] 後方に要約するとき、トレースイベントが状態からの遷移を記録する場合、それは好ましい。特定の実施形態の場合、これは、レンダリングエンジンが、所与の表示信号に対して最も最近に要約されたイベントと、任意の表示信号のために最も最近要約されたイベントとの間の期間にわたる状態を表示できるようにする。例えば、イベントからの遷移が使用されている図３３の上半分では、３３２０は、任意の表示信号のために最も最近に要約されたトレースイベントであり、３３１０は、スレッドＡと関連付けられた表示信号のために最も最近に要約されたトレースイベントである。３３１０でのイベントは、イベントが発生する前に状態が休止したことを記録する、イベントからの遷移であったため、レンダリングエンジンは、３３１０から、少なくとも３３２０が発生したときまでスレッドＡが休止状態にあったと推測できる。この時間の範囲は、３３００によって示される。イベントへの遷移が、図の下半分に示されるように、同様の状況で使用されているならば、レンダリングエンジンは、３３３０によって示される時間範囲の間、スレッドＡの状態を決定できないであろう。
【0112】
[0174] 上記に示される理由に類似する理由のため、前方に要約するとき、「への遷移」が好まれる。
【0113】
[0175] 図３４は、本発明の特定の実施形態において実装されてよいサマリストリームに記憶されたデータ要素の態様を示す例示的な図である。各データエントリ（３４００）は、（１）エントリ（３４１０）と関連付けられた開始タイムスタンプ及び終了タイムスタンプ、（２）エントリタイプ（３４２０）、及び（３）サマリエントリ（３４３０）の実際のコンテンツを指定する明示的な情報又は暗示的な情報を含む。
【0114】
[0176] 特定の実施形態では、サマリタイプ値（３４２０）は「未処理」、「サマリ」、又は「未処理参照」のどちらかである。そうした実施形態では、サマリタイプ値（３４２０）が「サマリ」である場合、タイムスタンプ値（３４１０）は、エントリの中の最初のデータ点及び最後のデータ点の開始タイムスタンプ及び終了タイムスタンプを示し、サマリコンテンツ（３４３０）は、本書の他の箇所に説明されるように、エントリを含むデータポイントの符号化された要約を含む。要約タイプ値（３４２０）が「未処理参照」である場合、タイムスタンプ値（３４１０）は、エントリの中の最初のデータ点及び最後のデータ点の開始タイムスタンプ及び終了タイムスタンプも示すが、サマリコンテンツ（３４３０）は空白である（特定の実施形態は、参照された未処理データのためのディスクの場所のポインタを符号化してよい）。しかしながら、要約タイプ値（３４２０）が「未処理」である場合、タイムスタンプ値（３４１０）は未処理データポイントのタイムスタンプにすぎず、サマリコンテンツ（３４３０）は、未処理データポイントを含む。
【0115】
[0177] 図３５に示されるように、サマリレベルジェネレータは、一連のサマリレベルを作成するために、未処理イベントのストリームを取り込む。あるレベルからのサマリエントリは、前の（つまり、より細かい）サマリレベルからのサマリエントリの量掛ける倍率に等しい時間量をカバーする。各サマリレベルからの出力は、任意選択でファイルストリーム（３５００）に書き込まれ、次のサマリレベル（３５１０）に送られる。
【0116】
[0178] 特定の実施形態では、各サマリレベルは、図３６に示されるように、一連のサマリ「バケツ」を含む。各バケツは、そのサマリレベルの中で一定のサイズを有し、それぞれがあらゆる増加するサマリレベルでより大きい倍率時間である。各サマリバケツは、その中に含まれるイベントの数、すべてのそれらのイベントのシグナチャ、及び実施態様の要件に応じた他の情報だけではなく、その期間の中に含まれるすべてのトレースイベントの表現も記憶する。期間は、２つのバケツが重複しないように、及び入力トレースイベントによりカバーされるすべての時間がバケツによって表されるように、一方で包括的であり、他方で排他的である。例えば、バケツ３６００は、１０秒まで、９秒直後に発生したすべてのイベントを含む。（包括的を示すための「[」及び排他的を示すための「]」を使用する時間範囲の数学的表記に留意されたい。）この場合、それらのイベントのうちの５つがあり、その値は１から１０に及んだ。特定の実施形態では、及び他の箇所に詳説される目的のために、バケツは、最初の未処理イベント及び最後の未処理イベントだけではなく、バケツの中に記憶されるイベントの最初の時間及び最後の時間も含む。例えば、バケツが未処理参照としてマークを付けられるかどうか等の他の情報も記憶されてよい。
【0117】
[0179] 図３６に示されるように、特定の実施形態はそれらがファイルに出力される前にどれほど多くのバケツがメモリに保持されるべきかを指定する（図及び他の箇所に「ウィンドウサイズ」として示される）「スライドウィンドウ」を有する。例えば、図３６では、新しいバケツ３６１０を加えることは、バケツ３６００を「スライドウィンドウの中から落とし」、従ってサマリファイルストリームへの出力のために評価される。
【0118】
[0180] 要約エンジンは、所与のサマリレベルの各バケツがカバーする期間を計算しなければならない。特定の実施形態は、同じプロセッサ上の２つのイベント（例えば、あるクロック目盛りと次のクロック目盛りとの間で経過した時間）の間で考えられる最小単位の時間を、倍率のカレントサマリレベル乗で乗算することによってこの期間を計算する。例えば、特定の実施態様の要件が、８の倍率を使用する場合、毎秒１，０００，０００，０００サイクル（１ＧＨｚ）で実行するターゲットを用いて、サマリレベル１０のバケツサイズは、（１秒／１，０００，０００，０００サイクル）＊（８＾１０）＝バケツあたり１．０７３７４１８２４秒となるであろう。
【0119】
[0181] 特定の実施形態では、入力データに応じて、要約エンジンは、すべてのサマリレベルを計算することを回避する。特定の実施形態は、これを達成するためにいろいろな技術を利用する。
（ａ）サマリレベルが未処理エントリ又は未処理参照エントリしか有していなかった（サマリエントリが生成されなかったことを意味する）場合、未処理ストリームからデータを読み取ることはより効率的であるだろうため、レベルを生成する必要はない。しかしながら、特定の実施形態は、レンダリングエンジンがデータを読み取るのと同時にサマリデータを生成するので、データの部分が要約され、特定のサマリレベルが必要とされない場合がある。しかしながら、後に、より高密度のデータが要約エンジンにレベルのためのサマリエントリを作成させる場合があり、これによりレベルはファイル内に作成される必要がある。この点で、サマリレベルは動的に作成することができ、そのデータのすべてはすでにサマリエントリを必要としないほど十分にまばらであると判断されているので、これにより書き込まれる第１のレコードは、未処理参照データである。
（ｂ）特定の実施形態は、ウィンドウの中からサマリバケツをまだ押し出していないサマリレベルのためのファイルにデータを書き込むことを遅れさせる。これは、要約エンジンが、スライドウィンドウ内のサマリバケツの数が確かめられるまでサマリレベルを出力するかどうかを判断するのを遅らせることを可能にする。
（ｃ）いろいろな最適化は、要約エンジンが、それが表示の効率的なレンダリングのために不必要であると判断するサマリレベルを出力するのを回避できるようにする。例えば、サマリレベルがそれの中にほとんどエントリを有していない場合、レンダリングエンジンは下方の次のサマリレベルからサマリエントリを読み取ることができるため、それは破棄できる。最高のサマリレベルが１００のサマリエントリを含んでおり、倍率が８であると仮定する。次のサマリレベルは、多くても８００サマリエントリを有するであろう。それらの８００のサマリエントリは、より高いレベルの１００のサマリエントリを作成するために使用された。レンダリングエンジンは、迅速に８００のサマリエントリを読み取ることができるため、１００エントリしか有していないより高いレベルを保持する必要はない。
（ａ）サマリレベルが未処理エントリ又は未処理参照エントリしか有していなかった（サマリエントリが生成されなかったことを意味する）場合、未処理ストリームからデータを読み取ることはより効率的であるだろうため、レベルを生成する必要はない。しかしながら、特定の実施形態は、レンダリングエンジンがデータを読み取るのと同時にサマリデータを生成するので、データの部分が要約され、特定のサマリレベルが必要とされない場合がある。しかしながら、後に、より高密度のデータが要約エンジンにレベルのためのサマリエントリを作成させる場合があり、これによりレベルはファイル内に作成される必要がある。この点で、サマリレベルは動的に作成することができ、そのデータのすべてはすでにサマリエントリを必要としないほど十分にまばらであると判断されているので、これにより書き込まれる第１のレコードは、未処理参照データである。
（ｂ）特定の実施形態は、ウィンドウの中からサマリバケツをまだ押し出していないサマリレベルのためのファイルにデータを書き込むことを遅れさせる。これは、要約エンジンが、スライドウィンドウ内のサマリバケツの数が確かめられるまでサマリレベルを出力するかどうかを判断するのを遅らせることを可能にする。
（ｃ）いろいろな最適化は、要約エンジンが、それが表示の効率的なレンダリングのために不必要であると判断するサマリレベルを出力するのを回避できるようにする。例えば、サマリレベルがそれの中にほとんどエントリを有していない場合、レンダリングエンジンは下方の次のサマリレベルからサマリエントリを読み取ることができるため、それは破棄できる。最高のサマリレベルが１００のサマリエントリを含んでおり、倍率が８であると仮定する。次のサマリレベルは、多くても８００サマリエントリを有するであろう。それらの８００のサマリエントリは、より高いレベルの１００のサマリエントリを作成するために使用された。レンダリングエンジンは、迅速に８００のサマリエントリを読み取ることができるため、１００エントリしか有していないより高いレベルを保持する必要はない。
【0120】
[0182] 要約エンジンは、レンダリングエンジンが、すでにファイルに公開されているデータを表示しているのと同時にオンザフライでより高いサマリレベル及びより低いサマリレベルを生成できる。
【0121】
[0183]簡略化された要約エンジンの例の動作
[0184] 要約エンジンの実施形態がここで説明される。スライドウィンドウ及び複数のサマリレベルに焦点を当てるための説明を簡略化するために、本実施形態は、値を要約することだけをサポートし、他の箇所で詳細に説明されるいくつかの他の機能は含めない。Ｐｙｔｈｏｎ言語で作成された要約エンジンの実施形態については、図３７Ａ～図３７Ｄを参照すること。この説明は、図の左側に位置する行番号で図を参照する。図３７Ａ～図３７Ｄの用語「分解能」は、その用語が本書全体で使用されるとき「サマリレベル」に相当する。以下の説明は、読者がそれらの図に説明される例の実施形態を理解するのを手助けするためのガイドとして作成されている。
[0184] 要約エンジンの実施形態がここで説明される。スライドウィンドウ及び複数のサマリレベルに焦点を当てるための説明を簡略化するために、本実施形態は、値を要約することだけをサポートし、他の箇所で詳細に説明されるいくつかの他の機能は含めない。Ｐｙｔｈｏｎ言語で作成された要約エンジンの実施形態については、図３７Ａ～図３７Ｄを参照すること。この説明は、図の左側に位置する行番号で図を参照する。図３７Ａ～図３７Ｄの用語「分解能」は、その用語が本書全体で使用されるとき「サマリレベル」に相当する。以下の説明は、読者がそれらの図に説明される例の実施形態を理解するのを手助けするためのガイドとして作成されている。
【0122】
[0185] トレースイベントは、一度に１つずつ逆の順序でループ内で処理される。トレースイベントを生成し、次いで要約する行１６９～１７３を参照すること。イベントごとに、
[0186] １．ファイル信号未処理ストリームにイベントを書き込む（行２０）。
[0187] ２．最も低いサマリレベルにイベントのシグナチャを加えることによって開始する（行２３）。各サマリレベルは、順にバケツの番号（行１４）を有する。各サマリレベルは、それより下方のサマリレベルよりも大きい倍率（行１２）であるバケツサイズを有する。バケツは、バケツが広がる時間範囲内に含まれるこれまで入力されたすべてのトレースイベントの表現を含む。バケツの例の定義については行５２を参照すること。
[0188] ３．新しい点が現在のサマリレベルの最新のバケツの時間範囲内に入る場合、点をそのバケツにマージする（行８１）。
[0189] ４．新しい点が現在のサマリレベルの最新のバケツ（行１４０）の時間範囲外になる場合、次の上方のサマリレベルに対してこのアルゴリズムを実行し、このサマリレベル（行８７）での最後のバケツを通過する。それが完了したら、新しい点を含むバケツを加えることが、スライドウィンドウ内で許可されるバケツの数を超えることを可能にするかどうかを確かめる（行９１及び行１１２）。可能にする場合、データとともにスライドウィンドウの中から落ちたすべてのバケツをファイルストリームに出力する。参照としてマークを付けられた連続的なバケツは、未処理データイベントに単一の参照として出力され（行１２５）、サマリとしてマークを付けられたバケツは、サマリエントリとして出力される（行１２９）。新しいイベントを保持するためのバケツを作成する（行９４）。ウィンドウ内のイベントの総数がサマリ閾値未満である場合、あらゆるバケツがそれを超えると参照となるバケツを指定することによってウィンドウ内のすべてのバケツに参照としてマークをつける（行１００）。
[0190] ５．要約エンジンのためのそれ以上の入力がなくなっても（行１７６）、各サマリレベルのスライドウィンドウ内のデータはまだ出力される。サマリレベルごとに、最低から最高へ、カレントバケツシグナチャは上方のレベルにマージされる（行３２）。（このステップがない場合、上方のサマリレベルは、最も最近加えられた点で欠測データになるであろう。）次いで、サマリレベルの中のすべてのバケツは、上述されたサマリエントリを生成するのか、それとも参照エントリを生成するのかについての同じ規則を使用し、シフトアウトされる（行３３及び行１１１）。
[0186] １．ファイル信号未処理ストリームにイベントを書き込む（行２０）。
[0187] ２．最も低いサマリレベルにイベントのシグナチャを加えることによって開始する（行２３）。各サマリレベルは、順にバケツの番号（行１４）を有する。各サマリレベルは、それより下方のサマリレベルよりも大きい倍率（行１２）であるバケツサイズを有する。バケツは、バケツが広がる時間範囲内に含まれるこれまで入力されたすべてのトレースイベントの表現を含む。バケツの例の定義については行５２を参照すること。
[0188] ３．新しい点が現在のサマリレベルの最新のバケツの時間範囲内に入る場合、点をそのバケツにマージする（行８１）。
[0189] ４．新しい点が現在のサマリレベルの最新のバケツ（行１４０）の時間範囲外になる場合、次の上方のサマリレベルに対してこのアルゴリズムを実行し、このサマリレベル（行８７）での最後のバケツを通過する。それが完了したら、新しい点を含むバケツを加えることが、スライドウィンドウ内で許可されるバケツの数を超えることを可能にするかどうかを確かめる（行９１及び行１１２）。可能にする場合、データとともにスライドウィンドウの中から落ちたすべてのバケツをファイルストリームに出力する。参照としてマークを付けられた連続的なバケツは、未処理データイベントに単一の参照として出力され（行１２５）、サマリとしてマークを付けられたバケツは、サマリエントリとして出力される（行１２９）。新しいイベントを保持するためのバケツを作成する（行９４）。ウィンドウ内のイベントの総数がサマリ閾値未満である場合、あらゆるバケツがそれを超えると参照となるバケツを指定することによってウィンドウ内のすべてのバケツに参照としてマークをつける（行１００）。
[0190] ５．要約エンジンのためのそれ以上の入力がなくなっても（行１７６）、各サマリレベルのスライドウィンドウ内のデータはまだ出力される。サマリレベルごとに、最低から最高へ、カレントバケツシグナチャは上方のレベルにマージされる（行３２）。（このステップがない場合、上方のサマリレベルは、最も最近加えられた点で欠測データになるであろう。）次いで、サマリレベルの中のすべてのバケツは、上述されたサマリエントリを生成するのか、それとも参照エントリを生成するのかについての同じ規則を使用し、シフトアウトされる（行３３及び行１１１）。
【0123】
[0191]トレースイベントの例の要約
[0192] 要約プロセスの説明を簡略化するために、説明される例の多くは、値型データの単一ファイル信号を要約する。当業者は、本書の他の箇所で提供される情報を使用し、いろいろな種類の複数のファイル信号を処理するために要約アルゴリズムの変形を実装できるであろう。
[0192] 要約プロセスの説明を簡略化するために、説明される例の多くは、値型データの単一ファイル信号を要約する。当業者は、本書の他の箇所で提供される情報を使用し、いろいろな種類の複数のファイル信号を処理するために要約アルゴリズムの変形を実装できるであろう。
【0124】
[0193] 図３８Ａ～図３８Ｃは、各入力イベントが本発明の実施形態に従って処理されるにつれ、データ要約が経時的に発生するであろうため、例示的な未処理の入力データストリーム及びデータ要約の対応するファイル出力を示す。スライドウィンドウの内部表現はこの例ではカバーされておらず、要約エンジンの実施形態の実行の入力及び出力だけがカバーされることに留意されたい。図３８Ａは、８秒間、１秒ごとに入力を有する例示的な未処理入力データストリームを示す。例えば、１秒でのタイムスタンプ、及び１０という値を有するイベントがある（３８００）。
【0125】
[0194] また、図３８Ａは、この例のアルゴリズムパラメータも説明する。パラメータ値は、例が本説明の目的のために過度に複雑化しないが、依然として興味深い動きを明示するように選ばれた。
ａ．倍率―サマリレベル間の時間倍率（この例では２に等しい）。
ｂ．ウィンドウサイズ―スライドウィンドウに含まれるサマリバケツの数（この例では２に等しい）。
ｃ．サマリ閾値―サマリが出力される前にウィンドウで必要とされるイベントの数。
ｄ．ファイルページサイズ―未処理ストリーム及びサマリ出力ストリームに事前に割り振られる出力ファイル内の記憶装置の数。ここの場合のように、特定の実施形態は、未処理イベントストリーム及びサマリストリームに割り当てられた異なる事前割当てサイズを有する。
ｅ．最も細かい表現可能時間―このデータセットが表すことができる時間の最小単位。
ａ．倍率―サマリレベル間の時間倍率（この例では２に等しい）。
ｂ．ウィンドウサイズ―スライドウィンドウに含まれるサマリバケツの数（この例では２に等しい）。
ｃ．サマリ閾値―サマリが出力される前にウィンドウで必要とされるイベントの数。
ｄ．ファイルページサイズ―未処理ストリーム及びサマリ出力ストリームに事前に割り振られる出力ファイル内の記憶装置の数。ここの場合のように、特定の実施形態は、未処理イベントストリーム及びサマリストリームに割り当てられた異なる事前割当てサイズを有する。
ｅ．最も細かい表現可能時間―このデータセットが表すことができる時間の最小単位。
【0126】
[0195] この例は、逆の時間順序で入力を処理することを明示し、従って検討される第１のイベントは１という値を有する８秒にある（８秒、１）。
【0127】
[0196] １．未処理イベントストリーム内にはこのイベントのために残された事前に割り振られた空間はなく、従って３つのファイルユニットが未処理ストリームで事前に割り振られ、第１のイベントは第１のファイルユニット（１）に書き込まれる。
【0128】
[0197] ２．次のイベント（７秒、７６）がファイルに加えられる。未処理ストリームにはまだ２つの空のファイルユニットがあるので、イベントは未処理ストリーム（２）の次の空のファイルユニット空間に加えられるだけである。
【0129】
[0198] ３．第３のイベント（６秒、１５０）は、ファイル（３）の未処理ストリームに加えられる。
【0130】
[0199] ４．第４のイベント（５秒、９９）が加えられる。ただし、既存の未処理イベントストリームにはそれ以上の空間は残されておらず、従って、未処理ファイルページは、未処理イベントストリームのためのファイルの終わりで事前に割り振られ、イベントはそのページ（４）の３つのファイルユニットのうちの第１のファイルユニットに記憶される。
【0131】
[0200] ５．第５のイベント（４秒、１２）が、ファイルの未処理ストリームに加えられる。このイベントは、要約エンジンに、サマリレベル１のための第３のサマリバケツを生成させる。ウィンドウサイズは２であるので、これは、最も古いレベル１のサマリをスライドウィンドウから落とさせる。これが起こるとき、スライドウィンドウ領域内には４つのイベントがあり、従ってサマリエントリが生成される。サマリエントリを記憶するための空間はなく、従って２つのファイルユニットは、サマリレベル１のイベントストリームのためのファイルの終わりに事前に割り振られ、７秒から８秒の点のサマリは、１～７６のシグナチャとともに、その新しいストリーム（５）の第１のエントリの中に記憶される。
【0132】
[0201] ６．第６のイベント（３秒、５２）が、ファイルの未処理ストリームに加えられる。未処理ファイルストリームの終わりにエントリのための事前に割り振られた空間があり、それはサマリレベル１のストリーム（６）の前に来るため、第６のイベントがファイルの最後に加えられないことに留意されたい。
【0133】
[0202] ７．第７のイベント（２秒、１００）が加えられる。ただし、既存の未処理イベントストリームにはそれ以上の空間がなく、従って３つのファイルユニットは、未処理イベントストリームのためのファイルの終わりに事前に割り振られ、イベントはそれらのユニットのうちの第１のユニットに記憶される。さらに、このイベントを加えることは、要約エンジンに、サマリレベル１のための第３のサマリバケツを生成させる。ウィンドウサイズは２であるので、これは、最も古いレベルのサマリをスライドウィンドウの中から落とさせる。これが起こるとき、スライドウィンドウには４つのイベントがあり、従ってサマリエントリが生成され、サマリレベル１のストリーム（７）の終わりに記憶される。
【0134】
[0203] ８．第８の最後のイベント（１秒、１０）が、未処理イベントストリーム（８）に加えられる。これ以上検討するトレースイベントはなく、従ってサマリレベルの残りのイベント及びサマリは、サマリ閾値規則に従って出力される。
【0135】
[0204] ９．サマリレベル１は、１２～５２のシグナチャを有する３秒から４秒、及び１０～１００のシグナチャを有する１秒から２秒の残された２つのバケツを有する。第１のバケツは、残りのサマリバケツの中に４つのイベントがあるため、サマリレベル１のストリームに出力され、これは３のサマリ閾値よりも多い。しかしながら、イベントを出力するために、２つのファイルユニットが、サマリレベル１のためのファイルの終わりに事前に割り振られ、次いでサマリエントリは、第１のファイルユニット（９）に書き込まれる。
【0136】
[0205] １０．３のサマリ閾値よりも低い、残りのスライドウィンドウの中には２つのイベントしかないため、レベル１のための第２のサマリバケツは出力されない。代わりに、第１の参照されたイベント時間が２秒である未処理参照データが出力され、この場合、何も残されていない（１０）が、残りのサマリバケツは検討されない。
【0137】
[0206] １１．サマリレベル２は、１～１５０のシグナチャを有する５秒から８秒、及び１０～１００のシグナチャを有する１秒から４秒の残された２つのバケツを有する。第１のバケツは、残りのサマリバケツの中に８つのイベントがあるため、サマリレベル２のストリームに出力され、これは３のサマリ閾値よりも多い。しかしながら、イベントを出力するために、２つのファイルユニットが、サマリレベル２のためのファイルの終わりに事前に割り振られ、次いでサマリエントリは、第１のファイルユニット（１１）に書き込まれる。
【0138】
[0207] １２．残りのサマリバケツの中に４つのイベントがあるため、レベル２のための第２のサマリバケツが出力され、これは３のサマリ閾値よりも多い（１２）。
【0139】
[0208] 図３９は、本発明の態様に従って逆の時間順序でトレースイベントのシーケンスを要約する例示的な詳細を示す。この例は、要約プロセスの出力だけではなく、異なるサマリレベルで生成されるツリーのような構造を表すことによって要約を明示する。出力は、出力ファイルのコンテンツ又は構造の逐語的な表現ではない。ファイルのフォーマット及びそのレイアウトの例は、他の箇所で説明される。トレースイベントのすべてが同時にメモリに維持される必要がないようにサマリレベルを構築する段階的なプロセスも、他の箇所に説明される。
【0140】
[0209] 図３９は、この例のアルゴリズムパラメータを説明する。パラメータ値は、例がこの説明のために過度に複雑化しないが、依然として興味のある動きを明示するように選ばれた。
[0210] ａ．倍率―サマリレベル間の時間倍率（この例では２に等しい）。
[0211] ｂ．ウィンドウサイズ―スライドウィンドウに含まれるサマリバケツの数（この例では２に等しい）。
[0212] ｃ．サマリ閾値―サマリが出力される前にウィンドウで必要とされるイベントの数（この例では３に等しい）。
[0213] ｄ．最も細かい表現可能時間―このデータセットが表すことができる時間の最小単位（この例では１秒に等しい）。
[0210] ａ．倍率―サマリレベル間の時間倍率（この例では２に等しい）。
[0211] ｂ．ウィンドウサイズ―スライドウィンドウに含まれるサマリバケツの数（この例では２に等しい）。
[0212] ｃ．サマリ閾値―サマリが出力される前にウィンドウで必要とされるイベントの数（この例では３に等しい）。
[0213] ｄ．最も細かい表現可能時間―このデータセットが表すことができる時間の最小単位（この例では１秒に等しい）。
【0141】
[0214] 図３９は、例のトレースイベントのために生成された３つのレベル－（バケツサイズ＝２秒を有する）レベル１のサマリ、（バケツサイズ＝４秒を有する）レベル２のサマリ、及び（バケツサイズ＝８秒）のレベル３のサマリ―の要約の視覚化を示す。
【0142】
[0215] 図３９でレベル１のサマリを生成するために、要約エンジンは最も最近のデータで開始する。８秒でのトレースイベント１及び７秒でのイベント７６は、６秒（除外）から８秒（包含）の時間に及ぶレベル１サマリバケツの範囲に入る。これらのトレースイベントは、バケツの中の最小値（１）及び最大値（７６）を記録するシグナチャ（１～７６）を有するサマリレベル１のバケツの中に記憶される。
【0143】
[0216] 同じプロセスは、サマリレベル１で次の３つのバケツを生成するために使用され、各バケツが２つのトレースイベントを要約し、時間範囲の間に重複はない。
【0144】
[0217] 図３９のレベル２のサマリは、レベル１のバケツのコンテンツから生成され、（倍率が２であるため）レベル１からのバケツの各対は、レベル２のサマリの単一のバケツにマージされる。例えば、１～７６のシグナチャを有する６秒（除外）から８秒（包含）のトレースイベントを含むバケツ、及び９９～１５０のシグナチャを有する４秒（除外）から６秒（包含）のトレースイベントを含むバケツは、１～１５０の値を有する４秒（除外）から８秒（包含）の新しいバケツにマージされる。同じプロセスは、レベル１の残りの２つのサマリエントリに適用されて、１０～１００のレベル２のサマリバケツを生成する。
【0145】
[0218] 最後に、次のレベルの要約（つまり、レベル３のサマリ）が、レベル２のサマリがレベル１のサマリから生成されたのと同じように、前のレベル（つまりレベル２のサマリ）から生成される。具体的には、１～１５０の値を有する４秒（除外）から８秒（包含）のサマリバケツは、１０～１００の値を有する０秒（除外）から４秒（包含）のサマリバケツとマージされて、１～１５０の値を有する０秒（除外）から８秒（包含）の新しいレベル３のサマリバケツを形成する。
【0146】
[0219] 図４０は、これらのサマリレベルのために出力されたファイル信号ストリームを示す。レベル１サマリストリーム（４０３０）、レベル２サマリストリーム（４０１０）、及びレベル３サマリストリーム（４０００）だけではなくすべての入力トレースイベント（４０４０）も含む未処理イベントストリームが出力される。最後のサマリエントリ出力の中に含まれる２つのトレースイベントしかないため、レベル１サマリストリームで出力された最後のレコードは未処理参照（４０２０）であり、サマリ閾値はこの例の場合３に設定されていた。レベル２サマリストリームは、最後のエントリが４つの点を含むため、未処理参照を有さず、これはサマリ閾値よりも大きい。
【0147】
[0220] 特定の実施形態は、未処理ファイルストリーム内の場所に対するポインタ、参照された未処理イベントを表す時間、又は同じサマリレベルでの最も近い非参照イベントの時間に基づいて暗示された時間として、未処理参照を記憶してよい。図３９の例は、参照されている未処理トレースイベントの時間を指定する。
【0148】
[0221] 図４１は、本発明の態様に係るデータ要約の例示的な詳細の別の一連の詳細を示す。図４１に示されるトレースイベント及び要約パラメータは、１つの例外を除き、図３９のトレースイベント及び要約パラメータと同じである。つまり、図４１では、６秒のタイムスタンプにデータ点はない。この例は、要約エンジンがサマリレベルの中でどのようにして未処理トレースイベントを保持するのかを明示する。
【0149】
[0222] レベル１サマリバケツのコンテンツは、９９の値を有する単一の未処理トレースイベントを含む、４秒（除外）から６秒（包含）のバケツを除き、図３９のコンテンツと同一である。これは、このバケツが表す期間が、９９の値を有する５秒での単一のトレースイベントしか含まないためである。特定の実施形態は、少数の未処理トレースイベント（この例では１）があるときバケツ内の未処理トレースイベントを記録することをサポートする。
【0150】
[0223] サマリレベル２を作成するためのプロセスは、シグナチャ１～７６及び９９～１５０を結合する代わりに、シグナチャ１～７６が未処理イベント値９９と結合されるのを除き、図３９の例のために使用されたプロセスと同じである。結果として生じるシグナチャは、１～９９である。これがサマリレベル３のためのバケツにマージされるとき、それは１～１００のシグナチャを生じさせる。
【0151】
[0224] 図４２の未処理イベントファイルストリームは、図４０の未処理イベントファイルストリームに類似している。ただし、図４２では、それは６秒に未処理イベントを含んでいない。さらに、図４２のレベル１サマリは、その第２のエントリ（４２２０）として未処理イベントを含み、レベル２サマリは１～９９（４２１０）の第１のエントリシグナチャを有し、レベル３サマリは１～１００（４２００）の第１のエントリシグナチャを有する。
【0152】
[0225]完全要約エンジンを用いない故障モードの例
[0226] 本特許が説明する要約手法は、特定の実施形態で、（１）トレースイベントを迅速にレンダリングできる、（２）すべてのイベントを検査する必要がない、（３）あらゆるピクセル実行単位の中ですべてのイベントについてなんらかの情報が提示される、及び（４）結果として生じるファイルが入力データよりも実質的に大きくないようにトレースイベントを符号化することを可能にする。要約システムのさまざまな部分がないと起こるであろうことを示す以下の例は、これがなぜ当てはまるのかを明示するのに役立つ。
[0226] 本特許が説明する要約手法は、特定の実施形態で、（１）トレースイベントを迅速にレンダリングできる、（２）すべてのイベントを検査する必要がない、（３）あらゆるピクセル実行単位の中ですべてのイベントについてなんらかの情報が提示される、及び（４）結果として生じるファイルが入力データよりも実質的に大きくないようにトレースイベントを符号化することを可能にする。要約システムのさまざまな部分がないと起こるであろうことを示す以下の例は、これがなぜ当てはまるのかを明示するのに役立つ。
【0153】
[0227] 第１の例は、特定の実施形態において本発明の態様に従ってサマリを有することがなぜ重要であるのかを明示する。サマリは、視聴者が、任意のズームレベルで表示を効率的にレンダリングすることを可能にする。
【0154】
[0228] 要約がないと、直接的に未処理データを読み取り、そのデータを表示されるビューに変換することによって、（いくつかの点だけが表示される画面）を迅速にレンダリングすることが可能である。しかしながら、ユーザがズームアウトすると、レンダリングエンジンは、画面上に新しい画像を表示するためにますます多数の点を考察しなければならない。最終的に、これはレンダリング速度に影響を与え始める。十分に多数の点が検査されなければならないとき、画像をレンダリングするには、数秒、数分、又は数時間も要する場合がある。
【0155】
[0229] サマリを用いれば、表示をレンダリングするために必要とされる情報は事前に計算され、必要とされる任意のズームレベルのために読取りが効率的な形式でファイルに格納される。最悪の場合、レンダリングエンジンは、ピクセル実行単位掛けるサマリエントリの倍率数の数、読み取らなければならない。これは、ピクセル実行単位によって表される期間が、最悪の場合のサマリレベルと完全には等しくないためである。結果として、次に下方のサマリレベルが読み取られなければならない。例えば、図４３を参照すること。図４３で、２つのサマリレベル―１秒に及ぶサマリレベル、及び０．２秒に及ぶサマリレベル（従って、この例の場合、倍率は５である）―が構築されている。レンダリングエンジンがユーザによって表示するように要求されているズームレベルで、各ピクセル実行単位は０．９９秒を表す。たとえ各ピクセル実行単位がほぼそのサイズであっても、レンダリングエンジンは、１秒で該サマリレベルを使用することができず、従ってレンダリングエンジンはより細かいサマリレベルを使用する。つまり、ピクセル実行単位の時間ごとに、５つのサマリエントリが読み取られる。
【0156】
[0230] レンダリングエンジンがサマリレベルから読み取った情報を使用し、レンダリングエンジンは次いで、現在の表示要件に適用する新しいサマリレベルを動的に作成できる。これは、再要約として知られている。再要約中、表示されているピクセル実行単位の境界内にあるサマリエントリの各集合体は、そのシグナチャを、サマリエントリが最初に要約中に作成されたのと同じようにマージさせる。例えば、シグナチャのビット論理和を使用することによって、又はすべてのエントリの最小値及び最大値を採取することによる。
【0157】
[0231] サマリを用いないと、１兆のトレースベントを含んだデータに対処するには、１兆のトレースイベントすべての線形走査が必要になる。しかしながら、モニタが、通常、幅数千ピクセルで測定される分解能を有することを考えると、サマリを使用することは、ファイル信号をレンダリングするために必要なデータを取り出すためには数千のサマリエントリ（又はより少ない）だけを読み取る必要があることを意味する。これは、レンダリングされる期間の中に含まれるトレースイベントの数に関わりなく当てはまる。
【0158】
[0232] 第２の例は、サマリエントリの代わりに、未処理参照を出力できることがなぜ重要であるのかを明示する。（未処理参照は、レンダリングエンジンに、ファイル信号未処理イベントストリームからデータを読み取るように命令する。）図４４で、１ミリ秒で分けられる２つのデータ点は、百万秒の間毎秒出力される。倍率は１０であり、最も細かい表現可能時間は１ミリ秒である。例えば少数のエントリを有するサマリレベルを破棄する等の任意の他の最適化がない場合、１０ミリ秒、１００ミリ秒、１秒、１０秒、１００秒、１０００秒、１０，０００秒、１００，０００秒、及び１，０００，０００秒のサマリレベルが構築され、出力されるであろう。サマリエントリは、点を含むバケツのために出力され、毎秒、２つの点を含むサイズ１０ミリ秒のバケツがあるため、これらのうち、１０ミリ秒のサマリレベルは未処理入力データのサイズの５０％となるであろう。同じ論理は、上記のサマリレベルにも当てはまる。毎秒、未処理入力データのサイズの５０％となるであろう、２つの点を含む１００ミリ秒のバケツがある。同は、１秒レベル（レベル４）でのサマリエントリについても言える。それらの３つのサマリレベルは、トレースイベントと同数のエントリの１５０％を有するであろう。レベル５（１０秒）は、各エントリの中で要約された２０のイベントを有し、従ってトレースイベントと同数のエントリの５％を含むであろう。レベル６は、その１０分の１を含み、レベル９まで同様であろう。従って、レベル５からレベル９は、トレースイベントと同数のエントリの５．５５５５％を含み、従って全体的な出力ファイルサイズのわずかな部分となるであろう。
【0159】
[0233] スライドウィンドウを使用しないと、出力されるサマリエントリの数は、入力されるトレースイベントの数の１５５．５５５５％になるであろう。データストレージ要件が非現実的になる場合があるので、これは、非常に多数のエントリに対処するときに理想的ではない。この例の場合、スライドウィンドウが１，０００バケツに設定され、ウィンドウあたりの点が１０，０００に設定されると、サマリレベルは、サマリレベル５（１０秒レベル）で開始し、出力されるにすぎないであろう。従って、この例では、出力ファイルは、入力されるトレースイベントの数よりも５．５５５５％多いイベントしか含まないであろう。
【0160】
[0234] 第３の例は、実施態様の要件に応じて、スライドウィンドウを取り入れて、未処理参照エントリがいつファイル信号のサマリストリームで生成されるのかを制限することがなぜ重要であるのかを明示する。最悪の場合、他のすべてのサマリエントリが未処理参照になるであろう。例えば、図４５は、トレースイベントが、多くの点と単一点との間で交互に起こり、これによりサマリレベルが一方又は他方の交互パターンを含むエントリを有するであろう例を示す。未処理参照の機能を用いると、これは他のすべてのエントリが、未処理参照である（４５００で示されるような）サマリレベルで表されるであろう。しかしながら、スライドウィンドウを用いると、要約エンジンは、代わりに未処理イベントをサマリレベル（４５１０）に直接的に出力し、これによりレンダリングエンジンは未処理イベントストリーム内の異なる場所を頻繁に求める必要はないであろう。
【0161】
[0235] スライドウィンドウ（４５００）を用いないと、レンダリングエンジンは、それぞれが少なくとも１つのファイルシーク及び読取りを必要とする多くのストリーム読取り動作を実行する必要があるであろう。最悪の場合、ファイル信号をレンダリングするためにレンダリングエンジンによって必要とされるストリーム読取り動作の数は、２で除算される、レンダリングするピクセル実行単位の数掛ける倍率となるであろう。この計算の理由は以下の通りである。（１）ピクセル実行単位の数は、レンダリングエンジンがどれほど多くのデータ点をレンダリングする必要があるのかを示す。少なくとも１つのトレースイベントが各ピクセル実行単位によってカバーされる期間内に含まれるため、最悪の場合、すべてのピクセル実行単位が、レンダリングエンジンが少なくとも１つのエントリを読み取ることを必要とする。（２）上記の例に詳説されるように、ピクセル実行単位が表す期間は、最も近いサマリレベルのサイズより非常にわずかに小さいため、最悪の場合、読み取られなければならないエントリの数は、倍率掛けるピクセル実行単位の数に等しくなる。（３）最悪の場合（及びこの例では）他のすべてのエントリは、未処理参照であり、従ってサマリレベルから読み取られるエントリの半分は、それらが表すピクセル実行単位に含まれるピクセルをレンダリングするために読み取られるストリームを必要とする。
【0162】
[0236] この例を所与として、ストレージのためにハードディスクドライブが使用されると、１００のディスクシークは通常約１秒を要するので、性能は非常に低くなるであろう。従って、最悪の場合、２０００ピクセル幅の表示で、８の倍率を使用し、単一ファイルシグナルにマッピングする単一表示信号をレンダリングすることは、８，０００ストリーム読取りを必要とし、これは、各ストリーム読取りが１ディスクシークを必要とするなら、約８０秒を要するであろう。これは、同時に画面上にある多くの異なる表示信号を用いて、毎秒何回も各表示信号をレンダリングするという目的を達成しないであろう。ソリッドステートディスク又は高速シークを有する他のファイルストレージ媒体の場合でも、多数のシークを実行することは適度に高価である。未処理データのキャッシングはいくぶん役に立つが、データセットがキャッシングに利用可能なメモリよりも大きくなると、レンダリング性能は損なわれる。
【0163】
[0237] 第４の例は、未処理データに対する参照が、出力ファイルのサイズ―特に、サマリによって使用されるデータの量―を未処理入力データに比して小さく保つために重要である別の場合を示す。
【0164】
[0238] 図４６で、１０億のトレースイベントがそれぞれ１秒で分けられる。データの終わりで、百万トレースイベントがそれぞれ１ナノ秒で分けられる。倍率は１０であり、ウィンドウサイズは１，０００バケツであり、サマリを書き出すためにウィンドウで必要とされるトレースイベントの数は１０，０００である。最も細かい表現可能時間は１ナノ秒である。
【0165】
[0239] それぞれ１ナノ秒で分けられる最後の百万トレースイベントは、それぞれ１０ナノ秒から１０秒のサマリレベルの作成を生じさせる。これを超える他のサマリレベルは、毎秒１トレースイベントを要約するために作成される。しかしながら、サマリデータで参照がないと、それぞれ１秒で分けられる１０億トレースイベントは、１０ナノ秒、１００ナノ秒等々おきに要約されるであろう。これは、１０の係数で出力されるデータの量を拡大し、１０億入力トレースイベントに対して、約９０億サマリエントリが作成されるであろうことを意味する。
【0166】
[0240] しかしながら、未処理参照データを用いると、１０ナノ秒から１０秒のサマリレベルはそれぞれ、最初の百万トレースイベントのためのサマリエントリを作成した後に、未処理参照データを生じさせるであろう。それらのサマリレベルには追加のデータは書き込まれないであろう。
【0167】
[0241]特定の実施形態での要約エンジン保証
[0242] 従って、特定の実施形態での変換アルゴリズムは、少なくとも以下の３つの重要な保証を提供する。
[0242] 従って、特定の実施形態での変換アルゴリズムは、少なくとも以下の３つの重要な保証を提供する。
【0168】
[0243] １．出力中のサマリエントリの数は、トレースデータイベント入力の数のうちの一部分によって抑制される。
【0169】
[0244] ２．レンダリングエンジンがレンダリングすることを希望する任意の所与の期間の間、読み取られる必要があるファイル内のエントリの数は、表示するためのピクセル実行単位の数の小さい倍数により抑制され、表示するためのピクセル数はウィンドウサイズに比例する。
【0170】
[0245] ３．レンダリングエンジンがレンダリングすることを希望する任意の所与の期間の間、ストリーム読み取りの数及び必要とされるシークの数は、表示するためのピクセル実行単位の数の一部分により抑制される。
【0171】
[0246]大量のデータの検索
[0247] トレースデータを検索することは、特定の実施形態において視覚化ツールの重要な機能である。テラバイトの情報に対処するときにこれらの検索を迅速に完了するために、例えば、ツールは、検索要求を完了するために走査されなければならないデータの量を削減するためのいくつかの手法を使用する。
[0247] トレースデータを検索することは、特定の実施形態において視覚化ツールの重要な機能である。テラバイトの情報に対処するときにこれらの検索を迅速に完了するために、例えば、ツールは、検索要求を完了するために走査されなければならないデータの量を削減するためのいくつかの手法を使用する。
【0172】
[0248] 特定の実施形態は、ユーザに、「検索範囲」と呼ばれる表示信号の部分集合を検索する方法を提供することによって検索空間を削減できる。例えば、図４７で、検索範囲（４７００）は、ディスパッチャ（４７２０）プロセス及びワーカ（４７１０）プロセスについての情報を含むにすぎない。ユーザにとって特に興味深いそれらの表示信号だけを検索することによって、特定の実施形態は、除外された表示信号と関連付けられたデータを無視できる。これは、キャッシュ性能を改善し、データを読み取るために必要とされるシークを最小限に抑える。
【0173】
[0249] 特定の実施形態は、ユーザに、ファイル内で表される総時間の部分集合を検索する方法を提供することによって検索空間を削減できる。例えば、図４８で、ユーザは、彼らが中で検索することに興味がある時間（４８１０）の選択を行っている。ボタン４８００をクリックすることによって、ユーザは、その時間範囲（４８２０）の中に含まれる結果だけに検索結果を制限できる。特定の実施形態では、各ファイル信号は時間で記憶され、並べ替えられ、これが、検索エンジンがいずれにせよ全データを処理する必要なく、選択された範囲外の全データを容易に無視できるようにする。
【0174】
[0250] 特定の実施形態は、トレースイベントを記憶するために使用されるＢ＋ツリーの部分を切り詰めることによって検索されたイベントの数を削減する。他の箇所で説明されるように、特定の実施形態は、Ｂ＋ツリーに要約されたデータを記憶し、それらは、要約された領域に含まれるイベントの種類についての基本情報を符号化するイベントシグナチャの要約されたグループを提供する。Ｂ＋ツリーの各非リーフノードは、サブノードに対するポインタのリストを記憶する。ノードに対するポインタごとに、特定の実施形態は、そのノードの中のすべてのデータのためのサマリシグナチャの表現も記憶する。例えば、整数値を表すファイル信号のシグナチャは、そのファイル信号内のすべてのイベントの最小値及び最大値の範囲である。各Ｂ＋ツリーノード内のすべてのイベントのシグナチャを記憶することによって、検索エンジンは、それが検索している値が、ノードのシグナチャの範囲外であるかどうかを判断できる。値が範囲外である場合、検索エンジンはノード及びそのすべての子を無視する（又は切り詰める）。例えば、図４９で、ルートノード（４９００）は、４つのサブノードに対するポインタを有する。それらのノードは、０～５０（４９４０）、５０～７５（４９３０）、９９～１００（４９２０）、及び２０～７５（４９１０）のシグナチャを有する。ユーザが値２５を検索する場合、検索エンジンはノード４９３０及び４９２０並びにそれらが指すすべてのデータを、検索エンジンはツリーのそれらの部分に含まれるデータがユーザが探している値を含むことはできないことをそれらのシグナチャから知っているため、無視する。同じ概念は、例えば文字列等の他の種類のシグナチャにも適用できる。他の箇所に文書化されるように、特定の実施形態の場合、未処理文字列イベントは、文字列テーブルの中にポインタとして記憶される。実際の文字列は、文字列テーブルに記憶される。シグナチャは、実施形態の要件に応じて、文字列自体の単一ビットハッシュ、又は文字列テーブル内の文字列のインデックスから生成される。文字列を検索するとき、検索される文字列の単一ビットハッシュが生成される。Ｂ＋ツリーノードは、それらのノード内にすべてのエントリの要約されたシグナチャを含み、これがＢ＋ツリーノード、従って走査されるべきである未処理イベントの除去を可能にする。
【0175】
[0251] 特定の実施形態では、検索空間を切り詰めるために生成されるシグナチャは、サマリファイルストリームに記憶されるサイズとは異なるサイズである。これは、サマリエントリが、通常、相対的に小さいシグナチャサイズを有するためである。例えば、特定の実施形態は６４ビットを使用する。しかしながら、６４ビットは、切り詰めにより検索空間を大幅に削減するためには十分ではない。代わりに、はるかに大きいＢ＋ツリーノードシグナチャを使用できる。例えば、特定の実施形態は１０２４ビットを使用する。これは、検索されている値が、検索されていない他の値と同じシグナチャハッシュを有する見込みを削減する。ファイル内の未処理エントリ又はサマリエントリに比較してＢ＋ツリーノードは相対的に少ないため、Ｂ＋ツリーノードエントリのためのこれらのより大きいシグナチャは、出力ファイルのサイズを大幅に拡大しない。
【0176】
[0252] また、この検索切り詰め手法は、特定の検索に対するすべての一致を探すときに適用できる。例えば、図５０で、ユーザは文字列「ｔｈｅ」を含むすべての文字列を検索している。ファイルの要約中に生成された文字列テーブルは、５つの異なる文字列「ｔｈｅ ｈｏｕｓｅ」、「ａ ｃａｔ」、「ｔｈｅ ｄｏｇ」、「ｆａｓｔ」、及び「ｓｌｏｗ」を含む。各文字列は、２ハッシュの累乗を与えられ、これにより各ハッシュのバイナリ表現は単一のビットセットを有する。サマリシグナチャは、そのサマリノードの中に含まれる文字列ごとのハッシュのビット論理和である。このシグナチャは、所与の文字列がサマリに含まれないかどうか、一定の時間内に判断するためのビットマスクの機能を果たすことができる。例えば、図５０で、クエリーに一致する検索用語は、「ｔｈｅ ｈｏｕｓｅ」及び「ｔｈｅ ｄｏｇ」であり、一致する結果を含むサマリノードが１ビットセット又は４ビットセットを有さなければならないことを意味する。中央のサマリノード（５０１０）は２ビットセット及び８ビットセットしか有していないため、検索は、この分岐内のすべてのイベントを無視できる。検索されたビットセットのうちの１つ以上を有する分岐は、一致する検索結果を含む場合もあれば、含まない場合もある。左サマリノード（５０００）は、いくつかの検索一致を含む。一方、右検索ノード（５０２０）は何も含まない。これは、「ｓｌｏｗ」及び「ｔｈｅ ｈｏｕｓｅ」と同様に、検索用語と一致する文字列が、検索用語と一致しない文字列とハッシュを共有する場合、発生する場合がある。
【0177】
[0253] 特定の実施形態では、複数の種類の検索が提供されてよい。例えば、
[0254] １．「検索」テキストフィールド内の文字列（５１００）を示す、図５１に表示されるようなテキスト文字列に対する一致を探す簡略なテキスト検索。
[0255] ２．図５２でのように、特定の状態が真である、時間の範囲を見つけるために複数のテキスト検索を使用できる高度な検索。この図は、ディスパッチャプロセスの任意のスレッドがユーザコード（５２００）を実行しており、一方ワーカプロセスのスレッドのいずれかがブロックされ（５２１０）、持続時間別に並べ替えられる（５２２０）すべての時間範囲を示す。
[0256] ３．図５３に表示されるような特定の関数のブラウズ。これは、特定の関数のあらゆるインスタンスの検索を可能にし、それは、どの呼出しが一番長かったのか、どの呼出しが一番短かったのか、どのくらい多くの呼出しがあったのか、それらはどのくらい長くかかったのか、及び最長期間中どの関数が実際に実行していたのか等の他の情報を確かめるのを容易にする。
[0254] １．「検索」テキストフィールド内の文字列（５１００）を示す、図５１に表示されるようなテキスト文字列に対する一致を探す簡略なテキスト検索。
[0255] ２．図５２でのように、特定の状態が真である、時間の範囲を見つけるために複数のテキスト検索を使用できる高度な検索。この図は、ディスパッチャプロセスの任意のスレッドがユーザコード（５２００）を実行しており、一方ワーカプロセスのスレッドのいずれかがブロックされ（５２１０）、持続時間別に並べ替えられる（５２２０）すべての時間範囲を示す。
[0256] ３．図５３に表示されるような特定の関数のブラウズ。これは、特定の関数のあらゆるインスタンスの検索を可能にし、それは、どの呼出しが一番長かったのか、どの呼出しが一番短かったのか、どのくらい多くの呼出しがあったのか、それらはどのくらい長くかかったのか、及び最長期間中どの関数が実際に実行していたのか等の他の情報を確かめるのを容易にする。
【0178】
[0257] 検索に一致するエントリのリストとして検索の結果を示すことは有用である。例えば、一致の総数等の検索結果についての統計を示すことも有用である。さらに、ある期間にわたり発生していたイベントの場合、一致が発生していた総時間、並びに最小時間、最大時間、及び平均時間等の統計も生成できる。
【0179】
[0258] しかしながら、ユーザがデータから収集を希望する場合があるなんらかの情報は、検索結果のリストから容易に確かめられない。例えば、検索結果は、多くの検索結果がある時点、及びなにもない他の時点があるかどうかを容易に示さない。特定の実施形態でこの情報を視覚化するために、これらの異なる種類の検索は、その結果を、グラフペイン内の新しい表示信号として表示することをサポートする。図５４は、ＳｙｎｃｈｒｏｎｏｕｓＳｅｎｄへの呼出しが新しい表示信号として表示される例を示す。検索結果は、固定幅の矩形によりグラフペイン内に表される。検索結果の値は、そのための空間がある場合は矩形の右側に示される。高度検索ウィンドウからの検索結果は、図５５に示されるように、（時点と関連付けられる結果を示す）固定幅の矩形又は表示がズームインされるにつれ、その幅が変化する（時間範囲と関連付けられる結果を示す）矩形によって表されてよい。
【0180】
[0259]時間を超えた単位を含む視覚化のための追加アプリケーション
[0260] 上記の要約及び視覚化の手法は、おもにタイムスタンプを押され、時間軸で見られるトレースイベントを考察することを説明してきた。また、同じ視覚化の手法は、トレースイベントが、例えば、ＣＰＵサイクル、キャッシュヒット又はキャッシュミス、送信／受信されたネットワークパケット、行われたシステムコール、デバイストランザクションの数、メモリ使用量、又はソフトウェアプログラムの開発において興味深いプログラムの態様を説明する任意の他の測定の単位等の他の単位と関連付けられるときにも適用する。実施態様の要件に応じて、呼出しスタックグラフと関連付けられるとき、これは特に興味深い場合がある。呼出しスタックグラフは、ソフトウェア開発者が容易に理解できるソフトウェア開発者の状況（プログラムでの関数の名前）及び実行の単位がその状況にどのように関係するのかを示すときに非常に強力なツールであるため、これは特に有用である。例えば、キャッシュ分析に関係する技術で既知のいくつかのデバッグ手法がある。概して、これらの手法は、多数のキャッシュミスがある、コードの特定の「ホットスポット」を識別できる。これは、それらのホットスポットの回りでコードを慎重に構造化することによって特定の種類のキャッシュ性能を最適化するのを手助けするために有用である。しかしながら、多くのキャッシュミスを有する関数の特定の領域についての情報は、それらの関数が呼び出される状況を明らかにしない。これは必要ではないこともあるが、その追加の状況が非常に有用であるときもある。例えば、分析された１つのアプリケーションでは、ｍｅｍｃｐｙは、キャッシュミスアクティビティのホットスポットであることが確かめられた。当初、アプリケーションの開発者は、これが、ｍｅｍｃｐｙが十分に実装さておらず、ｍｅｍｃｐｙライブラリ関数を開発した企業がそれを改善する必要があったことを暗示していたと考えた。しかしながら、ｍｅｍｃｐｙが多くのキャッシュミスを生成していた点の回りの呼出しスタックグラフを見ることによって、アプリケーションが、それがｍｅｍｃｐｙを呼び出す必要がまったくないように容易に修正できるであろうということは些末なことであった。
[0260] 上記の要約及び視覚化の手法は、おもにタイムスタンプを押され、時間軸で見られるトレースイベントを考察することを説明してきた。また、同じ視覚化の手法は、トレースイベントが、例えば、ＣＰＵサイクル、キャッシュヒット又はキャッシュミス、送信／受信されたネットワークパケット、行われたシステムコール、デバイストランザクションの数、メモリ使用量、又はソフトウェアプログラムの開発において興味深いプログラムの態様を説明する任意の他の測定の単位等の他の単位と関連付けられるときにも適用する。実施態様の要件に応じて、呼出しスタックグラフと関連付けられるとき、これは特に興味深い場合がある。呼出しスタックグラフは、ソフトウェア開発者が容易に理解できるソフトウェア開発者の状況（プログラムでの関数の名前）及び実行の単位がその状況にどのように関係するのかを示すときに非常に強力なツールであるため、これは特に有用である。例えば、キャッシュ分析に関係する技術で既知のいくつかのデバッグ手法がある。概して、これらの手法は、多数のキャッシュミスがある、コードの特定の「ホットスポット」を識別できる。これは、それらのホットスポットの回りでコードを慎重に構造化することによって特定の種類のキャッシュ性能を最適化するのを手助けするために有用である。しかしながら、多くのキャッシュミスを有する関数の特定の領域についての情報は、それらの関数が呼び出される状況を明らかにしない。これは必要ではないこともあるが、その追加の状況が非常に有用であるときもある。例えば、分析された１つのアプリケーションでは、ｍｅｍｃｐｙは、キャッシュミスアクティビティのホットスポットであることが確かめられた。当初、アプリケーションの開発者は、これが、ｍｅｍｃｐｙが十分に実装さておらず、ｍｅｍｃｐｙライブラリ関数を開発した企業がそれを改善する必要があったことを暗示していたと考えた。しかしながら、ｍｅｍｃｐｙが多くのキャッシュミスを生成していた点の回りの呼出しスタックグラフを見ることによって、アプリケーションが、それがｍｅｍｃｐｙを呼び出す必要がまったくないように容易に修正できるであろうということは些末なことであった。
【0181】
[0261] 一例に、特定の実施形態は、各キャッシュミスのときの呼出しスタックと関連付けられるキャッシュミスの数を示すために他の箇所で説明される要約及び視覚化の手法を使用する。あらゆる関数でのキャッシュミスの数を追跡すること、及び（１つのキャッシュミスが、それが以前は時間軸であるとして説明されていた、表示の軸の１つの単位に同等であるように）キャッシュミスの軸と呼出しスタックグラフを表示することによって、表示ではより大きく見える関数（及び関数のグループ）は、対応するより多くのキャッシュミスを有する。これは、最大数のキャッシュミスを含むコードの領域、及びコードのそれらの領域がなぜ実行していたのかを示すのに役立つ周囲のコンテクストを迅速に識別するのに役立つ。
【0182】
[0262] 各特定の実施態様の要件に応じて、この情報を生成するために必要な基本的なデータは、各関数の間の測定の単位の変化のログとともに、関数の入口及び出口のログであるであろう。代わりに、実施態様は、測定の単位の変化のたびに呼出しスタックを取り込むことを含んでよい。さらに、別の実施態様は、プログラムが実行する一意の関数呼出しチェーンごとに、測定の単位の変化を追跡するためのデータ構造を維持してよい。また、手法は、データをサンプリングするときに機能できる。例えば、特定の実施形態は、コンテクストスイッチごとにキャッシュミスをサンプリングする、及び／又はいくつかのキャッシュミスが検出されるたびにトレースイベントを出力する場合もある。（代替実態態様は、タイマでのキャッシュミスをサンプリングする可能性がある）。そうした実施形態は、次いで、実行された各関数が所与のサンプルに対してほぼ同数のキャッシュミスと考えた（ａｔｔｒｉｂｕｔｅｄ）と仮定することによりキャッシュミスの軸を用いて呼出しスタックグラフを表示できるであろう。この最終結果は、関数ごとにキャッシュミスの概算を示して、プログラマが、大部分のミスを引き起こす領域を狭める手助けとなることであろう。特定の実施形態は、さらにいくつかの方法でこの手法を改善できるであろう。例えば、ターゲットは、上記に詳説されるようにキャッシュミスの数についてのトレースイベントを生成できるであろう。実行されたすべての命令についての情報は、例えばＧｒｅｅｎ Ｈｉｌｌｓ ＳｕｐｅｒＴｒａｃｅ Ｐｒｏｂｅ等のハードウェアトレースデバイスによって取り込むことができるであろう。この命令情報は、次いでキャッシュミスを引き起こす場合があるであろう（例えば、キャッシュ可能な読取り及び書込み命令等の）唯一の命令がカウントされるようにキャッシュミス帰属手法を修正するために使用できるであろう。従って、プログラムフロー又は読取り／書込みレジスタを修正したにすぎないコードの領域は含まれないであろう。これは、キャッシュミスをトリガしていたプログラムの領域のはるかに正確な概算を生じさせるであろう。追加の最適化は、（ターゲットがそれをサポートしていた場合に、潜在的にデータトレース情報を含む）ハードウェアトレースデバイスからの命令データが、どの読取り／書込みがおそらくキャッシュミスをトリガしなかったのか、従ってキャッシュをミスを決定に帰するための正確な（又ははるかに詳細な概算）命令を判断するためにターゲットＣＰＵアーキテクチャのキャッシュモデルのシミュレーションに入れられる場合に行われるであろう。当業者は、各実施態様の特定の要件に応じて、追加の実施形態を容易に実施できる。
【0183】
[0263] 各特定の実施態様の要件に応じて、特定の実施形態は、追加の視覚化又は他の有用な情報を生成するためにデータに対して追加の処理を実行してよい。例えば、特定の実施形態は、その実行の単位の軸が、トレースイベントが収集されたときに依然として割り振られるグラフの各関数で割り振られるメモリの量である、関数呼出しスタックグラフを示すためにその実行のなんらかの点でプログラムのメモリ状態を視覚化してよい。
【0184】
[0264] 特定の実施形態では、ユーザは、それぞれの一意の経路関数呼出し経路で発生したメモリ割振りに関してデータを視覚化してよい。そうした実施形態は、プログラム実行で早期から考えられるメモリの無駄使いの説明を容易にしてよい。
【0185】
[0265] 各特定の実施態様の要件に応じて、追加の処理は、同等の関数呼出しスタックのそれぞれの単位を結合することを含む場合がある。各関数呼出しの中でメモリ割振りを追跡する実施形態では、これは、同等の関数呼出しシーケンスのすべての中で割り振られたバイトの総数がともに加えられる呼出しスタックグラフを生じさせるであろう。
【0186】
[0266] これらの手法を結合することによって、特定の実施形態は、例えば、システムで依然として割り振られ、どの関数呼出しシーケンスが最大のメモリ使用量を担うのかに従って大きさが決定されるメモリの量を視覚化してよい。これは、アプリケーション開発者に、彼らがシステムで割り振られるメモリの量を削減しようとしている場合、彼らがどの関数呼出しシーケンスに焦点を当てるべきかの迅速な視覚表示を与える。
【0187】
[0267]視覚化のための追加のアプリケーション
[0268] 本明細書で説明される特定の実施形態では、要約は、時間ベースのデータに対して実行されるとして説明されている。すなわち、そうした実施形態に係る要約は、時間の関数として変わるデータに関して実行される。しかしながら、概して、要約は、そのドメインが時間ベースではないデータに対して実行されてよい。例えば、要約は、そのドメインがメモリ割振りのサイズである、メモリ割振り時に収集されたトレースイベントデータに適用されてよい。さらに、例えば、そうしたデータは、コンピュータプログラムでの関数の実行のインスタンスすべてを、その関数の実行のそのインスタンスによって使用されるメモリの量とともに含んでよい。要約は、次いで時間の代わりにメモリ使用量に基づいてドメイン上でそのデータを処理するであろう。そうした要約の出力は、次いでその実行の単位がメモリ使用量である呼出しスタックグラフに使用することができ、呼出しスタックの関数の実行の各インスタンスの長さは、そのメモリ使用量に比例する。メモリ使用量に関する呼出しスタックグラフは、メモリ割振りが発生した順序で関数の実行の各インスタンスを表示するであろう。これは、開発者が、過剰なメモリ使用量の原因を迅速に見つけるのを手助けする。例えば、図３０Ｂを参照すること。
[0268] 本明細書で説明される特定の実施形態では、要約は、時間ベースのデータに対して実行されるとして説明されている。すなわち、そうした実施形態に係る要約は、時間の関数として変わるデータに関して実行される。しかしながら、概して、要約は、そのドメインが時間ベースではないデータに対して実行されてよい。例えば、要約は、そのドメインがメモリ割振りのサイズである、メモリ割振り時に収集されたトレースイベントデータに適用されてよい。さらに、例えば、そうしたデータは、コンピュータプログラムでの関数の実行のインスタンスすべてを、その関数の実行のそのインスタンスによって使用されるメモリの量とともに含んでよい。要約は、次いで時間の代わりにメモリ使用量に基づいてドメイン上でそのデータを処理するであろう。そうした要約の出力は、次いでその実行の単位がメモリ使用量である呼出しスタックグラフに使用することができ、呼出しスタックの関数の実行の各インスタンスの長さは、そのメモリ使用量に比例する。メモリ使用量に関する呼出しスタックグラフは、メモリ割振りが発生した順序で関数の実行の各インスタンスを表示するであろう。これは、開発者が、過剰なメモリ使用量の原因を迅速に見つけるのを手助けする。例えば、図３０Ｂを参照すること。
【0188】
[0269] 同様に、任意の他の適切なドメインは、各特定の実施態様の要件に応じて、特定の実施形態での要約のために使用されてよい。これらは、ＣＰＵサイクル、キャッシュヒット及びキャッシュミス、カーネルリソース使用量、アプリケーションリソース使用量、行われたシステムコール、デバイスリソース使用量、Ｉ／Ｏ帯域幅（例えば、ディスクシーク、ディスク読取り、ディスク書込み）、（送信又は受信されたパケット又はバイト等の）ネットワーク使用量、スタック使用量、センサデータ（例えば、温度、電力使用量、電流、電圧）、電池使用量、ハードウェアシステム構成要素使用量（例えば、絶対的な用語で又は他のそうした構成要素に比してのどちらかのＡＬＵ／ＦＰＵ／ＧＰＵ使用量、コプロセッサ使用量、バスアクセス等）、ハードウェア性能カウンタ、及び／又はソフトウェアプログラムの開発で興味深いプログラムの態様を説明する任意の他の適切な測定の単位を制限なく含んでよい。
【0189】
[0270] 別の例として、特定の実施形態は、キャッシュミス時に呼出しスタックと関連付けられたキャッシュミスの数を示すために、他の箇所で説明された要約及び視覚化の手法を使用してよい。あらゆる関数でキャッシュミスの数を追跡すること、及び１つのキャッシュミスが（以前に時間を示すとして説明された）表示の軸の１つの単位に同等となるように呼出しスタックグラフを表示することによって、表示より大きく見える関数（及び関数のグループ）は、対応するより大きい数のキャッシュミスを有する。これは、コンピュータプログラムの性能を低下させる場合がある、最大数のキャッシュミスを含むコードの領域を迅速に識別するのを手助けする。
【0190】
[0271] 各特定の実施態様の要件に応じて、特定の実施形態は、データに対して追加の処理を実行してよい。例えば、特定の実施形態は、依然として割り振られるその関数呼出しスタックによって割り振られるメモリの量によりそのサイズが決定される関数呼出しスタックを示すために、その実行でのなんらかの点でのプログラムのメモリ状態を視覚化してよい。この表示は、プログラム実行で早期からの考えられるメモリの無駄使いを示す。
【0191】
[0272] 各特定の実施態様の要件に応じて、追加処理は、同等な関数呼出しスタックのそれぞれの単位を結合することを含んでよい。各関数呼出しの中でメモリ割振りを追跡する実施形態では、これは同等な関数呼出しシーケンスのすべての中で割り振られるバイトの総数のビューを表示させる。
【0192】
[0273] 各特定の実施態様の要件に応じて、このトレースイベントデータを生成するために必要な基本データは、（１）各関数の間の測定の単位（例えば、バイト、キャッシュミス等）の変化のリストともに関数の入口及び出口のログ、（２）測定の単位の変化のたびの呼出しスタックを取り込むこと、及び／又は（３）プログラムが実行する一意の関数呼出しチェーンごとに、測定単位の変化を追跡するデータ構造を保持することを制限なく含んでよい。
【0193】
[0274]デバッグセッション情報の保存及びロード
[0275] 特定の実施形態は、後のとき及び／又は場所でロードし直すためのデバッグセッション－デバッグスナップショットと呼ばれるものを作成すること―に関係する情報のすべて又は部分を保存できる。デバッグセッションは、デバッグされているプログラム（「ターゲット」）の実行環境及びデバッガ自体の状態についての情報を含む。デバッグスナップショットは、つねに（存在する場合）ブックマーク及びそれらのブックマートと関連付けられたあらゆるメモとともに、ターゲットの状態の少なくとも一部を保存する。
[0275] 特定の実施形態は、後のとき及び／又は場所でロードし直すためのデバッグセッション－デバッグスナップショットと呼ばれるものを作成すること―に関係する情報のすべて又は部分を保存できる。デバッグセッションは、デバッグされているプログラム（「ターゲット」）の実行環境及びデバッガ自体の状態についての情報を含む。デバッグスナップショットは、つねに（存在する場合）ブックマーク及びそれらのブックマートと関連付けられたあらゆるメモとともに、ターゲットの状態の少なくとも一部を保存する。
【0194】
[0276] ブックマークは、デバッグセッション中にソフトウェア開発者によってマークを付けられる興味がある点であり、メモはそれらのブックマークに付けられてよい。ブックマークは、制限なく、特定の点、又はプログラムの実行のタイムラインでの時間の範囲、又は特定の行、行の範囲、又はプログラムの部分であるファイルと関連付けることができる。一般的に、ブックマークは、デバッグ情報の任意の表示又はデバッグセッションでのターゲットの状態に注釈を付けるために使用できる。例えば、ブックマークは、本書に説明されるトレースイベントデータの表示でソースコードの特定の行又は特定の時点に付けられてよく、プログラマは、特定のデバッグセッションについて調査されている故障でのソースコードのそれらのラインの役割についてそれらのブックマークにメモを加えてよい。デバッグスナップショットがロードされるとき、これらのブックマーク及びメモは、デバッグスナップショットが保存されたときにそれらが行ったのと同じ位置に表示される。また、ブックマークは特定と関連付けられてもよい。
【0195】
[0277] ブレイクポイント、情報ウィンドウ、及びインタラクションウィンドウ（例えば、可変ビューウィンドウ、レジスタウィンドウ、メモリビューウィンドウ、検索ウィンドウ）、コマンド行ウィンドウ及びその履歴、ビュー位置履歴、リスト中の項目の選択状態（例えば、リスト内で強調表示される項目）、並びに検索結果を含むデバッグセッションの他の態様は、保存され、復元されてよい。これらの項目が復元されると、該項目は、それらが保存されたときと実質的に同じに見える。復元されたデバッグセッションの特定の態様は、実質的効果なしに変化する場合がある。
【0196】
[0278] 例えば、ウィンドウサイズ、ウィンドウ位置、色、フォント、及び他の図形要素は、デバッグスナップショットを受け取り、復元するコンピュータシステムの差異の制限のため、復元時異なる場合がある。
【0197】
[0279] デバッグスナップショットは、ファイルに保存されてよい、サーバ又は後のとき又は異なる位置で読み取ることができる任意の他のコンピュータ可読媒体にアップロードされてよい。
【0198】
[0280] デバッグスナップショットによって保存される情報は、各特定態様の要件に従って、及び制限なく以下を含む。
（１）適切な場合、仮想対物理的なマッピングにより、すべてのＲＡＭ及びＲＯＭを潜在的に含む、ターゲットメモリ、
（２）ターゲットスレッドレジスタ状態、
（３）ターゲットで実行中のプログラム、
（４）ターゲットにロードされたプログラム、
（５）記号情報及びターゲット上でロードされる及び／又はターゲット上で実行するプログラムのデバッグメタデータを含むデバッグ情報、
（６）トレースイベント、
（７）その位置及びコンテンツを含むすべてのオープンウィンドウの状態、
（８）任意のコンソール出力、コマンド履歴、及びビュー位置履歴、
（９）現在選択されているスレッド、
（１０）ブレイクポイント（ハードウェア及びソフトウェア）、
（１１）見られている変数、
（１２）検索結果、
（１３）ブックマーク及びそれらのブックマークに対するメモ
（１４）ソースコード、及び／又は
（１５）デバッグセッション状態を再構築するために必要とされる場合がある任意の追加情報。
（１）適切な場合、仮想対物理的なマッピングにより、すべてのＲＡＭ及びＲＯＭを潜在的に含む、ターゲットメモリ、
（２）ターゲットスレッドレジスタ状態、
（３）ターゲットで実行中のプログラム、
（４）ターゲットにロードされたプログラム、
（５）記号情報及びターゲット上でロードされる及び／又はターゲット上で実行するプログラムのデバッグメタデータを含むデバッグ情報、
（６）トレースイベント、
（７）その位置及びコンテンツを含むすべてのオープンウィンドウの状態、
（８）任意のコンソール出力、コマンド履歴、及びビュー位置履歴、
（９）現在選択されているスレッド、
（１０）ブレイクポイント（ハードウェア及びソフトウェア）、
（１１）見られている変数、
（１２）検索結果、
（１３）ブックマーク及びそれらのブックマークに対するメモ
（１４）ソースコード、及び／又は
（１５）デバッグセッション状態を再構築するために必要とされる場合がある任意の追加情報。
【0199】
[0281] デバッグスナップショットによって保存されるターゲットの状態は、概してデバッグスナップショットにより保存されるデバッグセッションのインスタンスを作成し直すために必要な任意の情報を含む。すべてのターゲット状態が保存される、又はデバッガにとって有用であるわけではなく、従ってターゲットの状態は、ターゲットのあらゆる物理的な態様及び状態を含むことを意図されていない。
【0200】
[0282] この情報からデバッグセッションを復元することによって、開発者は、デバッガの同じ「ビュー」、及びそのターゲットの、スナップショットが撮影されたときと同じ状態を見ることができる。これは、制限なく以下を含む状況で有用である。
[0283] （１）時間シフトデバッグ：開発者は、そのターゲットに対するアクセスを維持することを必要とせずに、カレントタスクに対する作業を一時的に中断し、それを後で再開することを希望する。
[0284] （２）場所シフトデバッガ：開発者は、ハードウェアリソースが異なる目的に使用できるように、ハードウェアリソースを使用するのを停止することを希望する、及び／又は開発者は、異なる場所若しくはコンピュータに移動してその問題の分析を続行することを希望する。
[0285] （３）開発者シフトデバッガ：開発者は、別の開発者が問題を考察するための責任を負う必要があると考えるか、又は問題での別の開発者の手助けを有することを希望するかのどちらかである。
[0286] （４）バリデーション故障デバッグ：開発者及び／又は組織は、故障に遭遇した試験システムが、故障を追跡することにとって重要な情報を失うことなくバリデーションを実行し続けることを可能にすることを希望する。これは、ターゲットハードウェアの最適使用を可能にする。
[0283] （１）時間シフトデバッグ：開発者は、そのターゲットに対するアクセスを維持することを必要とせずに、カレントタスクに対する作業を一時的に中断し、それを後で再開することを希望する。
[0284] （２）場所シフトデバッガ：開発者は、ハードウェアリソースが異なる目的に使用できるように、ハードウェアリソースを使用するのを停止することを希望する、及び／又は開発者は、異なる場所若しくはコンピュータに移動してその問題の分析を続行することを希望する。
[0285] （３）開発者シフトデバッガ：開発者は、別の開発者が問題を考察するための責任を負う必要があると考えるか、又は問題での別の開発者の手助けを有することを希望するかのどちらかである。
[0286] （４）バリデーション故障デバッグ：開発者及び／又は組織は、故障に遭遇した試験システムが、故障を追跡することにとって重要な情報を失うことなくバリデーションを実行し続けることを可能にすることを希望する。これは、ターゲットハードウェアの最適使用を可能にする。
【0201】
[0287] 情報の共有を容易にするために、同じデバッグスナップショットを有する二人の開発者は、デバッグセッション情報（ウィンドウ位置、ブックマークメモ等）の「ビュー」だけを含む小さいファイルを保存し、ロードすることができる。完全なデバッグスナップショットは大きい場合があるが、ビュー情報は小さく、ｅメール又は他の転送機構を介して容易に共有できる。
【0202】
[0288]逆解凍
[0289] 多くのコンピュータシステムが生成するトレースデータの量により、多くの場合、ソフトウェア開発者にとって役立つ方法で分析し、表示するのには多大な時間を要す場合がある。このため、特定の実施形態は、ソフトウェア開発者が、多くの場合、トレース全体が分析されるのを待機する必要なく、迅速にトレース内の最も関連性のある情報を見ることを可能にするために本明細書に説明される２つの手法を結合してよい。
[0289] 多くのコンピュータシステムが生成するトレースデータの量により、多くの場合、ソフトウェア開発者にとって役立つ方法で分析し、表示するのには多大な時間を要す場合がある。このため、特定の実施形態は、ソフトウェア開発者が、多くの場合、トレース全体が分析されるのを待機する必要なく、迅速にトレース内の最も関連性のある情報を見ることを可能にするために本明細書に説明される２つの手法を結合してよい。
【0203】
[0290] 特定の実施形態に係る２つの結合可能な手法は、以下の通りである。
[0291] （１）トレースの終わりで開始し、トレースデータを（要約することを使用する手法を含む）分析し、後方に進行し、
[0292] （２）残りのトレースデータが分析され続ける間、部分的に分析された（及び／又は要約された）トレースデータを見る。
[0291] （１）トレースの終わりで開始し、トレースデータを（要約することを使用する手法を含む）分析し、後方に進行し、
[0292] （２）残りのトレースデータが分析され続ける間、部分的に分析された（及び／又は要約された）トレースデータを見る。
【0204】
[0293] この結合された技術は、２つの利点を有する。
[0294] （１）ソフトウェア開発者は、自分のトレースデータの考察をただちに開始できる。多くの場合、トレースデータのどの部分が検査されるのかに関わりなく、問題の原因を示す共通パターンが識別できる。
[0295] （２）多くの場合、問題の原因は、問題自体の直前に発生する。トレースが問題とともに終了する（又は問題が終わりに近い）とき、次いでトレースを後方に分析することは、問題の原因が、トレース全体が分析されるかなり前にソフトウェア開発者に可視となることを意味する。
[0294] （１）ソフトウェア開発者は、自分のトレースデータの考察をただちに開始できる。多くの場合、トレースデータのどの部分が検査されるのかに関わりなく、問題の原因を示す共通パターンが識別できる。
[0295] （２）多くの場合、問題の原因は、問題自体の直前に発生する。トレースが問題とともに終了する（又は問題が終わりに近い）とき、次いでトレースを後方に分析することは、問題の原因が、トレース全体が分析されるかなり前にソフトウェア開発者に可視となることを意味する。
【0205】
[0296]呼出しスタックグラフのリサイジング
[0297] 呼出しスタックは、多くの場合非常に深く、数千のエントリを含む場合がある。（例えば、本明細書の他の箇所に説明される時間、サイクル、キャッシュミス等―これは、要約されたデータを表示するために使用される「軸」と呼ばれることがある）なんらかの実行の単位に関して呼出しスタックグラフを示す表示にレンダリングされるとき、非常に深い呼出しスタックは、それらが非常に多くの空間を占有するため、見るのが困難である。例えば、特定の実施形態は、関数インスタンスごとに、呼出しスタックの各レベルで関数の名前を印刷する。有限数の関数名しか一時に画面上に収まり、依然として可読であることができないため、呼出しスタックグラフ全体をすぐに見ることは不可能である。呼出しスタックグラフ全体の一部を見るために表示をスクロールすることは可能であるが、それはいくつかの例では、プログラマに興味深い特定の種類のパターンを見ることを困難にする。これは、複数のスレッドの呼出しスタックグラフを同時に見ようと試みているときなおさら問題である。呼出しスタックグラフの回りでのズーミング及びパニングを可能にするビューを用いると、実行の単位のいくつかの点で、呼出しスタックは非常に浅くなり、他のときには非常に深くなるので、この問題はなおさらに悪化し、それらの深さがどれほど長く続くのかは、現在見られている実行の単位の範囲に基づいて変わる。
[0297] 呼出しスタックは、多くの場合非常に深く、数千のエントリを含む場合がある。（例えば、本明細書の他の箇所に説明される時間、サイクル、キャッシュミス等―これは、要約されたデータを表示するために使用される「軸」と呼ばれることがある）なんらかの実行の単位に関して呼出しスタックグラフを示す表示にレンダリングされるとき、非常に深い呼出しスタックは、それらが非常に多くの空間を占有するため、見るのが困難である。例えば、特定の実施形態は、関数インスタンスごとに、呼出しスタックの各レベルで関数の名前を印刷する。有限数の関数名しか一時に画面上に収まり、依然として可読であることができないため、呼出しスタックグラフ全体をすぐに見ることは不可能である。呼出しスタックグラフ全体の一部を見るために表示をスクロールすることは可能であるが、それはいくつかの例では、プログラマに興味深い特定の種類のパターンを見ることを困難にする。これは、複数のスレッドの呼出しスタックグラフを同時に見ようと試みているときなおさら問題である。呼出しスタックグラフの回りでのズーミング及びパニングを可能にするビューを用いると、実行の単位のいくつかの点で、呼出しスタックは非常に浅くなり、他のときには非常に深くなるので、この問題はなおさらに悪化し、それらの深さがどれほど長く続くのかは、現在見られている実行の単位の範囲に基づいて変わる。
【0206】
[0298] いくつかの実施態様は、垂直に呼出しスタックグラフを見て、呼出しスタックのそれぞれの新しいレベルは以前のレベルの下方に表示される。しかしながら、より深いレベルが以前のレベルの左又は右のどちらかに表示されるように、これを反転して（呼出しスタックレベルは、以前のレベルの上方に表示される）、又は水平に見る実施態様も可能であり、特定の実施形態では有利である。
【0207】
[0299] 呼出しスタックグラフの非常に深い呼出しスタックを表示することに関係する問題を解決するために、呼出しスタックグラフのサイズを変更して、表示上でより少ない空間を使用する機構を導入できる。特定の実施形態に従って呼出しスタックグラフのサイズを変更することに対する４つの態様がある。
[0300] （１）呼出しスタックグラフを表示するためにどれほど多くの空間が使用されるのかを制御するための方法、
[0301] （２）呼出しスタックグラフのために確保された空間が、呼出しスタックグラフ全体を完全に表示するには十分ではないとき呼出しスタックグラフを表示する方法を決定するための方法、
[0302] （３）最も興味深い呼出しスタック情報を見続けるために、どの呼出しスタックグラフエントリを折り畳むのかを判断するための方法、及び
[0303] （４）折り畳まれた呼出しスタックグラフを表示する方法を決定するための方法。
[0300] （１）呼出しスタックグラフを表示するためにどれほど多くの空間が使用されるのかを制御するための方法、
[0301] （２）呼出しスタックグラフのために確保された空間が、呼出しスタックグラフ全体を完全に表示するには十分ではないとき呼出しスタックグラフを表示する方法を決定するための方法、
[0302] （３）最も興味深い呼出しスタック情報を見続けるために、どの呼出しスタックグラフエントリを折り畳むのかを判断するための方法、及び
[0303] （４）折り畳まれた呼出しスタックグラフを表示する方法を決定するための方法。
【0208】
[0304] 本書が「現在可視である」呼出しスタックグラフの一部分を指すとき、本書は、表示エンジンによって表示されている実行の単位の所与の範囲の過程で発生した呼出しスタックグラフの部分を指す。重要なことに、呼出しスタックグラフの最大深さは、現在見られている実行の単位の範囲に基づいて異なる場合がある。特定の実施形態は、例えばパニング及びズーミング等の手段によって現在可視の部分を変更する。
【0209】
[0305] 必要とされているのは、呼出しスタックグラフを表示するためにどれほど多くの空間が使用されるのかを制御する手法、及び所与の実施態様が、呼出しスタックグラフ全体を完全に表示するために利用できる十分な空間を有していないとき、呼出しスタックグラフを表示する方法を制御するための方法である。
【0210】
[0306] 以下に説明されるとき、「視覚装置」は、モニタであるのか、印刷用紙であるのか、タブレットであるのか、電話であるのか、内蔵ディスプレイ付きのゴーグル又は眼鏡であるのか、その他であるのかに関わりなく、情報を見るための任意のデバイスを必然的に伴う。
【0211】
[0307] 以下に説明されるとき、「呼出しスタックエントリ」は、呼出しスタックグラフに示される特定の関数呼出しインスタンスを指す。例えば、図３０Ｂで、「ｆｕｎｃＥ」は、呼出しスタックエントリの例となるであろう。図２２の別の例は、２２３０によって参照される呼出しスタックグラフの部分内のエントリである「ＳｔａｒｔＴｉｌｅ」である。
【0212】
[0308] 呼出しスタックグラフを表示するためにどれほど多くの空間が使用されるのかを制御するための方法は、以下を含む場合があるが、これに限定されるものではない。
[0309] （ａ）ユーザは、サイズを手動で設定すること。例えば、ユーザは、呼出しスタックグラフの表示のサイズを設定するボタン（例えば、図３、ボタン３３０）をクリックし、ドラッグする可能性がある。
[0310] （ｂ）現在可視である最も深い読出しスタックを可能にするようにサイズを設定すること（つまり、現在可視の範囲内の任意の点での最も深い呼出しスタックが、サイズを決定するために使用される）。
[0311] （ｃ）視覚装置で利用可能な空間の量に比してサイズを設定すること。例えば、
[0312] （ｉ）ユーザが呼出しスタックグラフのより多くを見るためにスクロールする必要がないように、視覚装置で利用可能な空間全体にサイズを設定すること。及び
[0313] （ｉｉ）視覚装置で利用可能な空間の一部分にサイズを設定することであって、該一部分は、同時に見られている呼出しスタックグラフの数を超えるものである。特定の実施形態は、同時に同じ表示上にユーザが選択した数の異なるスレッドのための呼出しスタックグラフを表示するためにこの技術を使用できる。
[0309] （ａ）ユーザは、サイズを手動で設定すること。例えば、ユーザは、呼出しスタックグラフの表示のサイズを設定するボタン（例えば、図３、ボタン３３０）をクリックし、ドラッグする可能性がある。
[0310] （ｂ）現在可視である最も深い読出しスタックを可能にするようにサイズを設定すること（つまり、現在可視の範囲内の任意の点での最も深い呼出しスタックが、サイズを決定するために使用される）。
[0311] （ｃ）視覚装置で利用可能な空間の量に比してサイズを設定すること。例えば、
[0312] （ｉ）ユーザが呼出しスタックグラフのより多くを見るためにスクロールする必要がないように、視覚装置で利用可能な空間全体にサイズを設定すること。及び
[0313] （ｉｉ）視覚装置で利用可能な空間の一部分にサイズを設定することであって、該一部分は、同時に見られている呼出しスタックグラフの数を超えるものである。特定の実施形態は、同時に同じ表示上にユーザが選択した数の異なるスレッドのための呼出しスタックグラフを表示するためにこの技術を使用できる。
【0213】
[0314] これらの手法は、現在可視の範囲が変化するたびに、又はユーザ要求時に、独立して又は組み合わせて適用できる。
【0214】
[0315] 呼出しスタックグラフのために確保された空間が、呼出しスタックグラフ全体を完全に表示するには十分ではないとき呼出しスタックグラフを表示する方法を決定する方法は、以下を含むが、これに限定されるものではない。
[0316]（ａ）呼出しスタックグラフが利用可能な空間に収まるまで最も興味深くないと判断される呼出しスタックレベルを折り畳むこと。この手法を用いると、どの呼出しスタックエントリを折り畳むのかを判断するための方法は、可視範囲全体を使用する。例えば、単一の関数呼出しが、呼出しスタックの最も浅い５つのレベルのそれぞれに及ぶ現在可視の範囲を所与として、次いでそれらの５つのレベルをそれぞれ折り畳むことができるであろう。
[0317] （ｂ）利用可能な空間の中に収まらない呼出しスタックグラフの各部分の場合、該部分が利用可能な空間に収まるまで該部分の中で最も興味深くないと判断される呼出しスタックエントリのうちの１つ以上を折り畳むこと。この結果、呼出しスタックグラフが非常に深い多くの呼出しスタックエントリが折り畳まれ、一方より浅く、画面上に収まる呼出しスタックグラフの他の部分はその全体で示される。この手法を用いると、どの呼出しスタックエントリを折り畳むのかを判断するための方法は、可視範囲の部分集合を使用する。特定の実施形態では、折り畳まれた呼出しスタックエントリの数は、可視範囲の部分を区別するために折り畳まれたエントリの代わりに印刷される。また、特定の実施形態は、隣接する呼出しスタックエントリが、それらが異なる深さを表すので、必ずしも直接的に比較可能ではないことを示すために他のマーカーを表示してもよい。
[0316]（ａ）呼出しスタックグラフが利用可能な空間に収まるまで最も興味深くないと判断される呼出しスタックレベルを折り畳むこと。この手法を用いると、どの呼出しスタックエントリを折り畳むのかを判断するための方法は、可視範囲全体を使用する。例えば、単一の関数呼出しが、呼出しスタックの最も浅い５つのレベルのそれぞれに及ぶ現在可視の範囲を所与として、次いでそれらの５つのレベルをそれぞれ折り畳むことができるであろう。
[0317] （ｂ）利用可能な空間の中に収まらない呼出しスタックグラフの各部分の場合、該部分が利用可能な空間に収まるまで該部分の中で最も興味深くないと判断される呼出しスタックエントリのうちの１つ以上を折り畳むこと。この結果、呼出しスタックグラフが非常に深い多くの呼出しスタックエントリが折り畳まれ、一方より浅く、画面上に収まる呼出しスタックグラフの他の部分はその全体で示される。この手法を用いると、どの呼出しスタックエントリを折り畳むのかを判断するための方法は、可視範囲の部分集合を使用する。特定の実施形態では、折り畳まれた呼出しスタックエントリの数は、可視範囲の部分を区別するために折り畳まれたエントリの代わりに印刷される。また、特定の実施形態は、隣接する呼出しスタックエントリが、それらが異なる深さを表すので、必ずしも直接的に比較可能ではないことを示すために他のマーカーを表示してもよい。
【0215】
[0318] 「呼出しスタックエントリを折り畳む」が、なんらかの方法で呼出しスタックグラフ内のエントリのサイズを縮小することを意味することに留意されたい。従って、例えば、図３０Ｂで、メイン又はｆｕｎｃＤ及びｆｕｎｃＥ、又はｆｕｎｃＢ（又は任意の他の組合せであるがこれらは特定の実施形態に関連性がある場合があるいくつかの具体的な例を表す）を折り畳むことができるであろう。
【0216】
[0319] 用語「軸－ピクセル」がここで使用されるとき、それはピクセル実行単位ではなく、呼出しスタックグラフの深さの軸（いくつかの実施形態では、該軸の部分集合）に沿ったピクセルであることに留意されたい。例えば、呼出しスタックのより深いレベルがより浅いレベルの下方に置かれる（垂直軸が呼出しスタックグラフの深さである）呼出しスタックグラフでは、より浅いレベルを単一ピクセルのレベルまで折り畳むと、より浅いレベルの垂直サイズから１ピクセルを除くすべてがカットされ、すべてのより深いレベルがその呼出しスタックの垂直サイズから１ピクセルを引いた分、上方に移動するであろう。
【0217】
[0320] 最も興味深い呼出しスタックグラフ情報を見続けるためにどの呼出しスタックエントリを折り畳むのかを判断する方法は、以下を含むが、これに限定されるものではない。
[0321] （ａ）関連性のある可視範囲に及ぶ単一の関数呼出しがあるとき、呼出しスタックエントリを折り畳むこと。
[0322] （ｂ）それらのエントリのすべての関数呼出しが、関連性のある可視範囲における１ピクセル実行単位に満たない持続時間を有する場合、呼出しスタックエントリのグループを折り畳むこと。
[0323] （ｃ）呼出しスタックエントリが表すすべての関数呼出しがそれらと関連付けられたソースコードを有さない場合、呼出しスタックエントリを折り畳むこと。
[0324] （ｄ）呼出しスタックエントリが表すすべての関数呼出しが、（例えば、それらがシステムライブラリ若しくはサードパーティライブラリであるため、又はソースコードを見ている開発者によって所有されるコードではないため）開発者にとって興味深くない場合、呼出しスタックエントリを折り畳むこと。
[0321] （ａ）関連性のある可視範囲に及ぶ単一の関数呼出しがあるとき、呼出しスタックエントリを折り畳むこと。
[0322] （ｂ）それらのエントリのすべての関数呼出しが、関連性のある可視範囲における１ピクセル実行単位に満たない持続時間を有する場合、呼出しスタックエントリのグループを折り畳むこと。
[0323] （ｃ）呼出しスタックエントリが表すすべての関数呼出しがそれらと関連付けられたソースコードを有さない場合、呼出しスタックエントリを折り畳むこと。
[0324] （ｄ）呼出しスタックエントリが表すすべての関数呼出しが、（例えば、それらがシステムライブラリ若しくはサードパーティライブラリであるため、又はソースコードを見ている開発者によって所有されるコードではないため）開発者にとって興味深くない場合、呼出しスタックエントリを折り畳むこと。
【0218】
[0325] 折り畳まれた呼出しスタックグラフを表示する方法を決定する方法は、以下を含むが、これに限定されない。
[0326] （ａ）単一の軸―ピクセルの中に含まれるように呼出しスタックエントリを縮小すること。
[0327] （ｂ）複数の隣接する呼出しスタックエントリを単一の軸―ピクセルに収縮すること。
[0328] （ｃ）呼出しスタックエントリが表すことについての（色によって収集できること以外の）情報を表示するために十分な広さがないときも呼出しスタックエントリが依然として可視で存在するように、呼出しスタックエントリを高さで少数の軸―ピクセルとなるように縮小すること。及び
[0329] （ｄ）呼出しスタックエントリが何の機能を表すのかを見ることが依然として可能であるようにであるが、それが折り畳まれていない呼出しスタックレベルより少ない空間を使用するように、小さいフォントを使用することによって呼出しスタックエントリを縮小すること。
[0326] （ａ）単一の軸―ピクセルの中に含まれるように呼出しスタックエントリを縮小すること。
[0327] （ｂ）複数の隣接する呼出しスタックエントリを単一の軸―ピクセルに収縮すること。
[0328] （ｃ）呼出しスタックエントリが表すことについての（色によって収集できること以外の）情報を表示するために十分な広さがないときも呼出しスタックエントリが依然として可視で存在するように、呼出しスタックエントリを高さで少数の軸―ピクセルとなるように縮小すること。及び
[0329] （ｄ）呼出しスタックエントリが何の機能を表すのかを見ることが依然として可能であるようにであるが、それが折り畳まれていない呼出しスタックレベルより少ない空間を使用するように、小さいフォントを使用することによって呼出しスタックエントリを縮小すること。
【0219】
[0330]要約に基づいたデータ分析
[0331] 要約は、その間に大量のトレースデータが分析され、視覚分析のために画面上に迅速に表示できる形式に変換されるプロセスである。また、特定の実施形態は、他の種類の分析のために要約されたデータを使用する。これらの他の種類の分析は、パターン又は特定のイベントを検索すること、及びイベントのプロパティに関する統計を生成することを含んでよいが、これに限定されるものではない。
[0331] 要約は、その間に大量のトレースデータが分析され、視覚分析のために画面上に迅速に表示できる形式に変換されるプロセスである。また、特定の実施形態は、他の種類の分析のために要約されたデータを使用する。これらの他の種類の分析は、パターン又は特定のイベントを検索すること、及びイベントのプロパティに関する統計を生成することを含んでよいが、これに限定されるものではない。
【0220】
[0332] 特定の実施形態では要約に対するいくつかの重要な態様がある。
[0333] （ａ）タイムスタンプが押されたトレースイベントの受け取られたストリームから複数のサマリエントリを生成すること。
[0334] （ｉ）例えば図３１Ｃ、図３１Ｄ、及び図３５に示されるように、トレースイベントは（本書の他の箇所に説明されるように、潜在的に特定の実施形態では、例えば未処理イベントを生成すること、トレースイベントシグナチャを構築すること等の動作を行う場合がある処理の後に）受け取られ、サマリエントリの集合に要約される。
[0335] （ｉｉ）本書の他の箇所に詳細に説明されるように、特定の実施形態は、これらのサマリエントリを使用して、表示されている領域の中に含まれるすべてのトレースイベントについての情報を最初に読み取る必要なく、表示装置に何を表示するのかを迅速に決定するためのレンダリングエンジンを含む。
[0336] （ｂ）該サマリエントリのそれぞれは、複数のサマリレベルのうちの１つ以上と関連付けられる。
[0337] （ｉ）例えば図３１Ｃ、図３５に示されるように、構築されるサマリエントリは、特定のサマリレベルに割り当てられる。
[0338] （ｉｉ）本書の他の箇所に詳細に説明されるように、特定の実施形態は、ピクセル実行単位によってカバーされる期間（又は他の適用可能な実行の単位）を決定し、次いで該期間以下のスパンを有するサマリエントリを含むサマリレベルから読み取るためのレンダリングエンジンを含む。
[0339] （ｃ）該サマリエントリのそれぞれは、複数の該タイムスタンプが押されたイベントを表す。
[0340] （ｉ）サマリエントリは、トレースイベントのすべての部分集合の表現である。
[0333] （ａ）タイムスタンプが押されたトレースイベントの受け取られたストリームから複数のサマリエントリを生成すること。
[0334] （ｉ）例えば図３１Ｃ、図３１Ｄ、及び図３５に示されるように、トレースイベントは（本書の他の箇所に説明されるように、潜在的に特定の実施形態では、例えば未処理イベントを生成すること、トレースイベントシグナチャを構築すること等の動作を行う場合がある処理の後に）受け取られ、サマリエントリの集合に要約される。
[0335] （ｉｉ）本書の他の箇所に詳細に説明されるように、特定の実施形態は、これらのサマリエントリを使用して、表示されている領域の中に含まれるすべてのトレースイベントについての情報を最初に読み取る必要なく、表示装置に何を表示するのかを迅速に決定するためのレンダリングエンジンを含む。
[0336] （ｂ）該サマリエントリのそれぞれは、複数のサマリレベルのうちの１つ以上と関連付けられる。
[0337] （ｉ）例えば図３１Ｃ、図３５に示されるように、構築されるサマリエントリは、特定のサマリレベルに割り当てられる。
[0338] （ｉｉ）本書の他の箇所に詳細に説明されるように、特定の実施形態は、ピクセル実行単位によってカバーされる期間（又は他の適用可能な実行の単位）を決定し、次いで該期間以下のスパンを有するサマリエントリを含むサマリレベルから読み取るためのレンダリングエンジンを含む。
[0339] （ｃ）該サマリエントリのそれぞれは、複数の該タイムスタンプが押されたイベントを表す。
[0340] （ｉ）サマリエントリは、トレースイベントのすべての部分集合の表現である。
【0221】
[0341] 特定の実施形態での要約に対するこれらの重要な部分を超えて、各実施態様の要件に応じて、特定の実施形態は、以下の追加の態様のうちの１つ以上を用いて要約を実施してよい。
[0342] （ａ）サマリエントリは、時間範囲（又は他の実行の単位）と関連付けられる。
[0343] （ｉ）図３４及び図３１Ｄに示されるように、サマリエントリは、それらが関連付けられる実行の単位についての情報を含む場合がある。特定の実施形態では、レンダリングエンジンはこの情報を使用して、画面上のどこにサマリエントリのグラフィック表現を表示するのかを決定し、表示装置に表示されるべきであるサマリエントリのサマリレベルを、実行の単位別で二分検索する。
[0344] （ｂ）サマリエントリは、サイズを有するサマリエントリシグナチャを含み、該サマリエントリシグナチャのそれぞれは、該それぞれのサマリエントリによって表される該タイムスタンプが押されたトレースイベントの集合のためにトレースイベントシグナチャの集合をマージすることによって作成される。
[0345] （ｉ）図３４及び図３１Ｄに示されるように、サマリエントリは、トレースイベントを表すサマリエントリシグナチャを含む。このサマリエントリシグナチャのトレースイベントシグナチャからの構築は、他の箇所に詳説されている。
[0346] （ｃ）各トレースイベントシグナチャは、単一ビットハッシュを使用し、対応するタイムスタンプが押されたトレースイベントから生成される。
[0347] （ｉ）トレースイベントシグナチャは、実施態様の要件に応じて多くの方法を使用し、生成できる。一例に、単一ビットハッシュは、トレースイベントの値から作成できる。これは、例えば文字列及び関数呼出し等の、データを表すトレースイベントにとって特に有用である。
[0348] （ｄ）サマリエントリシグナチャは、サマリエントリの時間範囲の中で発生したトレースイベントの表現を含む。
[0349] （ｉ）各特定の実施態様の要件に応じて、サマリエントリシグナチャは、サマリエントリが表している時間範囲（又は他の実行の単位）の中のすべてのトレースイベントのトレースイベントシグナチャから構築される。本書の他の箇所に説明されるように、要約の前に起こる処理ステップのために、いくつかのトレースイベントが除外されてよいことに留意されたい。図３１Ａ、３１１０を参照すること。
[0350] （ｉｉ）その実施態様の要件に応じて、特定の実施形態は、いろいろな表現手法を使用する。これらは、表されるイベントの数、又は値の若しくは基本的なトレースイベントのシグナチャの合計、倍数、平均、あるいは他の数学表現を含んでよいが、これに限定されるものではない。表現手法の追加の例は、本書の他の箇所に詳説されている。
[0351] （ｅ）サマリエントリシグナチャは、該サマリエントリと関連付けられた時間範囲（又は他の実行の単位）の中で発生した該タイムスタンプが押されたトレースイベントのすべてよりも少ない表現を含む。
[0352] （ｉ）実施態様の要件に応じて、サマリエントリシグナチャは、サマリエントリの時間範囲の中の特定のトレースイベントを含まない場合がある。例えば、特定の実施形態では、その時間範囲の中のトレースイベントの最小値から最大値を表すサマリエントリシグナチャは、例えば無限又は数ではない等の特別な値を除外してよい。これらの特別な値は、異常であり、表示するために興味深くないと見なされる場合がある。他の実施形態は、異常値だけを示すことを希望し、許容通常範囲からのすべての値を除外する場合がある。
[0353] （ｆ）サマリエントリシグナチャは、該サマリエントリと関連付けられた時間範囲の中で発生したトレースイベント、及び該サマリエントリと関連付けられた時間範囲（又は他の実行の単位）の中で発生しなかった１つ以上のタイムスタンプが押されたトレースイベントの表現を含む。
[0354] （ｉ）実施態様の要件に応じて、サマリイベントシグナチャは、サマリイベントと関連付けられた時間範囲の外の特定のトレースイベントを含んでよい。例えば、特定の実施形態では、隣接するサマリエントリに特定の値を含めることによって、特定の値がそうでなければ目立つよりも目立たせることが所望される場合がある。他の実施形態は、おそらく、特に注目に値する状態が現在アクティブであることを示すために、特定のトレースイベントを、サマリエントリの範囲のシグナチャ内で「長引く」ように見えさせることを希望する場合がある。
[0355] （ｇ）サマリエントリシグナチャのサイズは、サマリエントリが表すトレースイベントの数とは無関係である。
[0356] （ｉ）各実施態様の要件に応じて、特定の実施形態は、サイズが、サマリエントリシグナチャが表すトレースイベントの数によって決定されないサマリエントリシグナチャを使用する。その実施態様の要件に応じて、特定の実施形態は、サマリエントリごとに異なるサイズを使用してもよい。
[0357] （ｈ）各サマリエントリシグナチャのサイズは、サマリレベルごとに固定される。
[0358] （ｉ）それぞれの実施形態の要件に応じて、特定の実施形態は、所与のサマリレベルですべてのサマリエントリに固定サイズのサマリエントリシグナチャを使用する。固定サイズのシグナチャは、どれほど多くのトレースイベントがサマリエントリによって表されていても、サマリエントリはつねに同じサイズとなることを意味する。これは、特定の実施形態が、悪くてもトレースイベントの数とともにサイズが直線状であり、良くても対数関数である、抑制された空間の量で、潜在的には複数のレベルのサマリエントリを用いて、任意の数のトレースイベントを表すことを可能にする。
[0359] （ｉｉ）各実施態様の要件に応じて、特定の実施形態が、異なる要約ストリームに異なる固定サイズ、及び／又は同じトレースイベントストリームに異なるサマリレベルを使用してよいことに留意されたい。例えば、これは、テキストデータのためのサマリストリームが、数値データとは異なるサマリシグナチャサイズを使用できるようにする。また、これは、異なるサマリレベルが、より大きい数の基本的なトレースイベントとなる可能性があることについてのより詳細な情報をそれが表すことができるようにする、より大きなサマリシグナチャを有するためにより大きな時間の範囲をカバーするサマリエントリを有することを可能にする。
[0360] （ｉ）サマリレベルの中のサマリエントリの時間範囲のそれぞれの期間のスパンは同じである。
[0361] （ｉ）各実施態様の要件に応じて、特定の実施形態は、各サマリエントリが表す固定サイズ期間を使用する。サマリエントリは、異なる時間の範囲を表すが、各範囲の期間は、すべてのエントリに対して同じとなる。
[0362] （ｉｉ）各実施態様の要件に応じて、特定の実施形態が、異なるサマリストリームに異なる固定サイズ期間を、及び／又は同じトレースイベントストリームに異なるサマリレベルを使用してよいことに留意されたい。
[0363] （ｊ）所与のサマリレベルで各サマリエントリによって表される時間の範囲は、重複していない。
[0364] （ｉ）各実施態様の要件に応じて、特定の実施形態は、サマリエントリに重複していない時間の範囲を表させる。特定の実施態様は、サマリエントリが連続的であるという要件を有していない。これは、実施態様が、トレースイベントを含まない時間の範囲があるときにデータを記憶しないことを可能にする。
[0365] （ｋ）所与のサマリレベルのサマリエントリによって表される期間は、隣接するサマリレベルの倍数である。
[0366] （ｉ）各実施態様の要件に応じて、特定の実施形態は、トレースイベントのストリームを複数のサマリレベルに要約させる。各サマリレベルは、特定の期間を表すサマリエントリを有し、隣接するサマリレベルは、互いの倍数である期間を表すサマリエントリを有する。例えば、サマリレベル１は、サマリエントリごとに１秒を表し、（サマリレベル１及び３に隣接する）サマリレベル２は、サマリエントリごとに１０秒を表し、（サマリレベル２に隣接する）サマリレベル３は、サマリエントリごとに１００秒を表すことがあるであろう。
[0367] （ｉｉ）各実施態様の要件に応じて、特定の実施形態は、要約された異なるトレースストリームに異なる倍数を使用してよい。例えば、文字列を含むトレースストリームの倍数は５である場合があるであろうが、整数値を含むトレースイベントの倍数は１０である場合があるであろう。
[0368] （ｌ）所与のサマリレベルのサマリエントリによって表される期間は、次のサマリレベルよりも小さい８の係数である。
[0369] （ｉ）各実施態様の要件に応じて、特定の実施形態は、隣接する各サマリレベル間の差に８の倍率を使用する。
[0370] （ｉｉ）８の倍率は、最適化される以下の領域を所与とすると、優れたトレードオフであると実験的に判断されている。
[0371] （Ａ）生成されるサマリレベルの数：より大きい倍率は、より少ないサマリレベルを生じさせ、従ってサマリレベルにより少ない記憶空間を使用する。
[0372] （Ｂ）サマリレベル間の「距離」：レンダリングエンジンが、各ピクセル実行単位によってカバーされる期間が減少するため（例えば、以前の表示が、ピクセル実行単位ごとにサマリエントリ期間で、又はサマリエントリ期間をわずかに超えて使用していたときのズームレベルの非常にわずかな上昇のため）あるサマリレベルからより細かいサマリレベルに切り替えるとき、次いで（他の箇所に説明されるように）読み取られ、再要約される必要があるサマリエントリの数は、より大きな係数の場合大きくなり、より小さい係数の場合小さくなる。
[0373] （Ｃ）必要とされる計算は、それが２の累乗であるので容易である。コンピュータは、例えば単純なビットシフトを用いて、２の累乗に関係する乗算及び除算を容易に行うことができる傾向がある。本書の他の箇所に説明される演算の多くは、選ばれる倍率に基づいた乗算又は除算を必要とする。
[0374] （ｍ）各サマリエントリシグナチャは、視覚的に異なるグラフィック表現と関連付けられる。
[0375] （ｉ）その実施態様の要件に応じて、特定の実施形態は、サマリエントリシグナチャを画面に表示されるなにかに変換することによって表示装置上にグラフィック表現を表示する。シグナチャを視覚表示に変換するための手法は、本書の他の箇所でカバーされているが、重要な特性は、異なるイベントを表す任意の２つのシグナチャが、少なくとも同じように見える可能性が低い点である。
[0376] （ｉｉ）例えば、その実施態様の要件に応じて、特定の実施形態では、あるサマリエントリが、値が１～５０に及ぶトレースイベントを表し、別のサマリエントリが、値が２５～７５に及ぶトレースイベントを表す場合、次いで１つのシグナチャ表現はその時間範囲内のトレースイベントの最小値及び最大値となり、グラフィック表現は、最小値から最大値へのデータプロットであるであろう。従って、これらの２つの表現は、これらの例の値について互いとは視覚的に異なるであろう。
[0377] （ｎ）第１のサマリエントリシグナチャは、第２のサマリエントリシグナチャとは異なる。
[0378] （ｉ）２つのサマリエントリシグナチャが、互いから異なることが理想的である。これは、実施態様の要件に依存する、選ばれたシグナチャ生成マージアルゴリズムに依存する。
[0379] （ｏ）第１のサマリエントリシグナチャと関連付けられた第１の１つ以上のタイムスタンプが押されたトレースイベントが、第２のサマリエントリシグナチャと関連付けられた１つ以上のタイムスタンプが押されたトレースイベントとは異なる場合、第１のサマリエントリシグナチャは第２のサマリエントリシグナチャとは異なる。
[0380] （ｉ）理想的には、２つのサマリイベントが、異なる値を有するトレースイベントを表すとき、次いでそのサマリイベントシグナチャも異なる。これは、それらのサマリイベントシグナチャのグラフィックレンダリングも異なるようにできる。この目標を達成するためにシグナチャ生成アルゴリズム及びマージアルゴリズムを構築することは、本書の他の箇所に説明される。
[0381] （ｐ）タイムスタンプが押されたトレースイベントはそれぞれ、最初に、生成されたシグナチャを有し、それらのシグナチャは、サマリエントリのためにシグナチャを作成するためにマージされる。
[0382] （ｉ）各実施態様の要件に応じて、特定の実施形態は、サマリエントリのためにサマリシグナチャを生成するために、トレースイベントのシグナチャをマージしてよい。シグナチャをマージする方法は、本書の他の箇所に説明されている。
[0342] （ａ）サマリエントリは、時間範囲（又は他の実行の単位）と関連付けられる。
[0343] （ｉ）図３４及び図３１Ｄに示されるように、サマリエントリは、それらが関連付けられる実行の単位についての情報を含む場合がある。特定の実施形態では、レンダリングエンジンはこの情報を使用して、画面上のどこにサマリエントリのグラフィック表現を表示するのかを決定し、表示装置に表示されるべきであるサマリエントリのサマリレベルを、実行の単位別で二分検索する。
[0344] （ｂ）サマリエントリは、サイズを有するサマリエントリシグナチャを含み、該サマリエントリシグナチャのそれぞれは、該それぞれのサマリエントリによって表される該タイムスタンプが押されたトレースイベントの集合のためにトレースイベントシグナチャの集合をマージすることによって作成される。
[0345] （ｉ）図３４及び図３１Ｄに示されるように、サマリエントリは、トレースイベントを表すサマリエントリシグナチャを含む。このサマリエントリシグナチャのトレースイベントシグナチャからの構築は、他の箇所に詳説されている。
[0346] （ｃ）各トレースイベントシグナチャは、単一ビットハッシュを使用し、対応するタイムスタンプが押されたトレースイベントから生成される。
[0347] （ｉ）トレースイベントシグナチャは、実施態様の要件に応じて多くの方法を使用し、生成できる。一例に、単一ビットハッシュは、トレースイベントの値から作成できる。これは、例えば文字列及び関数呼出し等の、データを表すトレースイベントにとって特に有用である。
[0348] （ｄ）サマリエントリシグナチャは、サマリエントリの時間範囲の中で発生したトレースイベントの表現を含む。
[0349] （ｉ）各特定の実施態様の要件に応じて、サマリエントリシグナチャは、サマリエントリが表している時間範囲（又は他の実行の単位）の中のすべてのトレースイベントのトレースイベントシグナチャから構築される。本書の他の箇所に説明されるように、要約の前に起こる処理ステップのために、いくつかのトレースイベントが除外されてよいことに留意されたい。図３１Ａ、３１１０を参照すること。
[0350] （ｉｉ）その実施態様の要件に応じて、特定の実施形態は、いろいろな表現手法を使用する。これらは、表されるイベントの数、又は値の若しくは基本的なトレースイベントのシグナチャの合計、倍数、平均、あるいは他の数学表現を含んでよいが、これに限定されるものではない。表現手法の追加の例は、本書の他の箇所に詳説されている。
[0351] （ｅ）サマリエントリシグナチャは、該サマリエントリと関連付けられた時間範囲（又は他の実行の単位）の中で発生した該タイムスタンプが押されたトレースイベントのすべてよりも少ない表現を含む。
[0352] （ｉ）実施態様の要件に応じて、サマリエントリシグナチャは、サマリエントリの時間範囲の中の特定のトレースイベントを含まない場合がある。例えば、特定の実施形態では、その時間範囲の中のトレースイベントの最小値から最大値を表すサマリエントリシグナチャは、例えば無限又は数ではない等の特別な値を除外してよい。これらの特別な値は、異常であり、表示するために興味深くないと見なされる場合がある。他の実施形態は、異常値だけを示すことを希望し、許容通常範囲からのすべての値を除外する場合がある。
[0353] （ｆ）サマリエントリシグナチャは、該サマリエントリと関連付けられた時間範囲の中で発生したトレースイベント、及び該サマリエントリと関連付けられた時間範囲（又は他の実行の単位）の中で発生しなかった１つ以上のタイムスタンプが押されたトレースイベントの表現を含む。
[0354] （ｉ）実施態様の要件に応じて、サマリイベントシグナチャは、サマリイベントと関連付けられた時間範囲の外の特定のトレースイベントを含んでよい。例えば、特定の実施形態では、隣接するサマリエントリに特定の値を含めることによって、特定の値がそうでなければ目立つよりも目立たせることが所望される場合がある。他の実施形態は、おそらく、特に注目に値する状態が現在アクティブであることを示すために、特定のトレースイベントを、サマリエントリの範囲のシグナチャ内で「長引く」ように見えさせることを希望する場合がある。
[0355] （ｇ）サマリエントリシグナチャのサイズは、サマリエントリが表すトレースイベントの数とは無関係である。
[0356] （ｉ）各実施態様の要件に応じて、特定の実施形態は、サイズが、サマリエントリシグナチャが表すトレースイベントの数によって決定されないサマリエントリシグナチャを使用する。その実施態様の要件に応じて、特定の実施形態は、サマリエントリごとに異なるサイズを使用してもよい。
[0357] （ｈ）各サマリエントリシグナチャのサイズは、サマリレベルごとに固定される。
[0358] （ｉ）それぞれの実施形態の要件に応じて、特定の実施形態は、所与のサマリレベルですべてのサマリエントリに固定サイズのサマリエントリシグナチャを使用する。固定サイズのシグナチャは、どれほど多くのトレースイベントがサマリエントリによって表されていても、サマリエントリはつねに同じサイズとなることを意味する。これは、特定の実施形態が、悪くてもトレースイベントの数とともにサイズが直線状であり、良くても対数関数である、抑制された空間の量で、潜在的には複数のレベルのサマリエントリを用いて、任意の数のトレースイベントを表すことを可能にする。
[0359] （ｉｉ）各実施態様の要件に応じて、特定の実施形態が、異なる要約ストリームに異なる固定サイズ、及び／又は同じトレースイベントストリームに異なるサマリレベルを使用してよいことに留意されたい。例えば、これは、テキストデータのためのサマリストリームが、数値データとは異なるサマリシグナチャサイズを使用できるようにする。また、これは、異なるサマリレベルが、より大きい数の基本的なトレースイベントとなる可能性があることについてのより詳細な情報をそれが表すことができるようにする、より大きなサマリシグナチャを有するためにより大きな時間の範囲をカバーするサマリエントリを有することを可能にする。
[0360] （ｉ）サマリレベルの中のサマリエントリの時間範囲のそれぞれの期間のスパンは同じである。
[0361] （ｉ）各実施態様の要件に応じて、特定の実施形態は、各サマリエントリが表す固定サイズ期間を使用する。サマリエントリは、異なる時間の範囲を表すが、各範囲の期間は、すべてのエントリに対して同じとなる。
[0362] （ｉｉ）各実施態様の要件に応じて、特定の実施形態が、異なるサマリストリームに異なる固定サイズ期間を、及び／又は同じトレースイベントストリームに異なるサマリレベルを使用してよいことに留意されたい。
[0363] （ｊ）所与のサマリレベルで各サマリエントリによって表される時間の範囲は、重複していない。
[0364] （ｉ）各実施態様の要件に応じて、特定の実施形態は、サマリエントリに重複していない時間の範囲を表させる。特定の実施態様は、サマリエントリが連続的であるという要件を有していない。これは、実施態様が、トレースイベントを含まない時間の範囲があるときにデータを記憶しないことを可能にする。
[0365] （ｋ）所与のサマリレベルのサマリエントリによって表される期間は、隣接するサマリレベルの倍数である。
[0366] （ｉ）各実施態様の要件に応じて、特定の実施形態は、トレースイベントのストリームを複数のサマリレベルに要約させる。各サマリレベルは、特定の期間を表すサマリエントリを有し、隣接するサマリレベルは、互いの倍数である期間を表すサマリエントリを有する。例えば、サマリレベル１は、サマリエントリごとに１秒を表し、（サマリレベル１及び３に隣接する）サマリレベル２は、サマリエントリごとに１０秒を表し、（サマリレベル２に隣接する）サマリレベル３は、サマリエントリごとに１００秒を表すことがあるであろう。
[0367] （ｉｉ）各実施態様の要件に応じて、特定の実施形態は、要約された異なるトレースストリームに異なる倍数を使用してよい。例えば、文字列を含むトレースストリームの倍数は５である場合があるであろうが、整数値を含むトレースイベントの倍数は１０である場合があるであろう。
[0368] （ｌ）所与のサマリレベルのサマリエントリによって表される期間は、次のサマリレベルよりも小さい８の係数である。
[0369] （ｉ）各実施態様の要件に応じて、特定の実施形態は、隣接する各サマリレベル間の差に８の倍率を使用する。
[0370] （ｉｉ）８の倍率は、最適化される以下の領域を所与とすると、優れたトレードオフであると実験的に判断されている。
[0371] （Ａ）生成されるサマリレベルの数：より大きい倍率は、より少ないサマリレベルを生じさせ、従ってサマリレベルにより少ない記憶空間を使用する。
[0372] （Ｂ）サマリレベル間の「距離」：レンダリングエンジンが、各ピクセル実行単位によってカバーされる期間が減少するため（例えば、以前の表示が、ピクセル実行単位ごとにサマリエントリ期間で、又はサマリエントリ期間をわずかに超えて使用していたときのズームレベルの非常にわずかな上昇のため）あるサマリレベルからより細かいサマリレベルに切り替えるとき、次いで（他の箇所に説明されるように）読み取られ、再要約される必要があるサマリエントリの数は、より大きな係数の場合大きくなり、より小さい係数の場合小さくなる。
[0373] （Ｃ）必要とされる計算は、それが２の累乗であるので容易である。コンピュータは、例えば単純なビットシフトを用いて、２の累乗に関係する乗算及び除算を容易に行うことができる傾向がある。本書の他の箇所に説明される演算の多くは、選ばれる倍率に基づいた乗算又は除算を必要とする。
[0374] （ｍ）各サマリエントリシグナチャは、視覚的に異なるグラフィック表現と関連付けられる。
[0375] （ｉ）その実施態様の要件に応じて、特定の実施形態は、サマリエントリシグナチャを画面に表示されるなにかに変換することによって表示装置上にグラフィック表現を表示する。シグナチャを視覚表示に変換するための手法は、本書の他の箇所でカバーされているが、重要な特性は、異なるイベントを表す任意の２つのシグナチャが、少なくとも同じように見える可能性が低い点である。
[0376] （ｉｉ）例えば、その実施態様の要件に応じて、特定の実施形態では、あるサマリエントリが、値が１～５０に及ぶトレースイベントを表し、別のサマリエントリが、値が２５～７５に及ぶトレースイベントを表す場合、次いで１つのシグナチャ表現はその時間範囲内のトレースイベントの最小値及び最大値となり、グラフィック表現は、最小値から最大値へのデータプロットであるであろう。従って、これらの２つの表現は、これらの例の値について互いとは視覚的に異なるであろう。
[0377] （ｎ）第１のサマリエントリシグナチャは、第２のサマリエントリシグナチャとは異なる。
[0378] （ｉ）２つのサマリエントリシグナチャが、互いから異なることが理想的である。これは、実施態様の要件に依存する、選ばれたシグナチャ生成マージアルゴリズムに依存する。
[0379] （ｏ）第１のサマリエントリシグナチャと関連付けられた第１の１つ以上のタイムスタンプが押されたトレースイベントが、第２のサマリエントリシグナチャと関連付けられた１つ以上のタイムスタンプが押されたトレースイベントとは異なる場合、第１のサマリエントリシグナチャは第２のサマリエントリシグナチャとは異なる。
[0380] （ｉ）理想的には、２つのサマリイベントが、異なる値を有するトレースイベントを表すとき、次いでそのサマリイベントシグナチャも異なる。これは、それらのサマリイベントシグナチャのグラフィックレンダリングも異なるようにできる。この目標を達成するためにシグナチャ生成アルゴリズム及びマージアルゴリズムを構築することは、本書の他の箇所に説明される。
[0381] （ｐ）タイムスタンプが押されたトレースイベントはそれぞれ、最初に、生成されたシグナチャを有し、それらのシグナチャは、サマリエントリのためにシグナチャを作成するためにマージされる。
[0382] （ｉ）各実施態様の要件に応じて、特定の実施形態は、サマリエントリのためにサマリシグナチャを生成するために、トレースイベントのシグナチャをマージしてよい。シグナチャをマージする方法は、本書の他の箇所に説明されている。
【0222】
[0383] 本明細書の要約の説明は、おもに（多くの場合「時間軸」と呼ばれる）時間の単位に従って情報を表示することとの関連である。これは説明を簡略化する。しかしながら、時間以外の実行の単位も使用することができ、時間以外の単位を有する軸を生じさせる。
【0223】
[0384] 例えば、図２は、データを要約するためのレンダリングエンジンの実施形態を示す。要素２６５は、要素２８５、「グラフ領域」に示される各イベントの時間の相互関係を示す「時間軸」を示す。本実施形態では、時間軸を横切る各ピクセル実行単位は、時間の範囲を表し、グラフ領域内の各ピクセルは、所与の信号と関連付けられたトレースイベントのレンダリングを垂直に表し、時間の範囲は水平に時間軸によって示される通りである。従って、信号内の特定の点を表すとき、その点が発生した時間は、時間軸上で同じピクセルを水平に下方に見ることによって決定できる。その左のイベントはその時点の前となり、右のイベントはその後になる。
【0224】
[0385] 要約されたトレースデータを表示するこの手法は、時間を超える他の単位にも適用する。具体的には、タイムスタンプが押されたトレースイベントのストリームは、代わりにそれぞれが実行の単位と関連付けられたトレースイベントの受け取られたストリームである場合がある。各実施態様の要件に応じて、特定の実施形態は、タイムスタンプが押されたトレースイベントからこれらの他の実行の単位を抽出してよい。他の実施形態は、タイムスタンプを有さないトレースイベントを使用する。例えば、タイムスタンプの代わりに、トレースイベントは、サイクルカウント又は計器カウントを有してよい。特定の実施形態は、実行の単位を暗示的に決定できる。例えば、トレースイベントがあらゆる命令で生成される場合、次いで命令カウントは、トレースイベント自体が命令番号を含むことを必要とせずに決定できる。
【0225】
[0386] 要約の概念は、実行と関連付けることができる任意の単位に適用できる。例えば、
（ａ）時間、
（ｂ）サイクル、又は実行されるＣＰＵクロックの数に関係する他の単位、
（ｃ）実行された命令、
（ｄ）キャッシュミス、キャッシュヒット、又は他のキャッシュに関係する統計、
（ｅ）割り振られた（Ｃ／Ｃ＋＋用語ではｍａｌｌｏｃされた）、解放された、現在確保されている、若しくは現在空いているメモリ、または所与の呼出しスタックレベルに割り振られたメモリの変化、
（ｆ）グラフィックフレーム、
（ｇ）ネットワークパケット、
（ｈ）移動距離、
（ｉ）割込み、
（ｊ）消費電力、又は
（ｋ）電圧。
（ａ）時間、
（ｂ）サイクル、又は実行されるＣＰＵクロックの数に関係する他の単位、
（ｃ）実行された命令、
（ｄ）キャッシュミス、キャッシュヒット、又は他のキャッシュに関係する統計、
（ｅ）割り振られた（Ｃ／Ｃ＋＋用語ではｍａｌｌｏｃされた）、解放された、現在確保されている、若しくは現在空いているメモリ、または所与の呼出しスタックレベルに割り振られたメモリの変化、
（ｆ）グラフィックフレーム、
（ｇ）ネットワークパケット、
（ｈ）移動距離、
（ｉ）割込み、
（ｊ）消費電力、又は
（ｋ）電圧。
【0226】
[0387] 例として、呼出しスタックグラフは、実行の単位が時間で、レンダリングできる。これは、図３、要素３２０のように見え、関数入口イベント及び関数出口イベントが、それらが発生した時点と相互に関連付けられている。代わりに、呼出しスタックグラフは、実行の単位が電力でレンダリングされ、関数の入口イベント及び関数の出口イベントは、消費電力量と相互に関連付けられるであろう。このようにして見られると、最も多くの電力が消費されたときにプログラムの実行で点を決定することは容易であるであろう。実行の単位の他の例、及びその呼出しスタックグラフに対する影響。
[0388] （ａ）実行の単位は、割り振られるメモリである。これは、それらの中で実行される割振りのサイズを占めるとして関数を表示するであろう。
[0389] （ｂ）実行の単位はメモリの変化である。これは、関数に遭遇するときと対照的に、関数が終了されるとき割り振られるメモリの差をとるとして関数を表示するであろう。従って、例えば、関数が、割り振られた１０２４バイトで入力され、関数が別の５１２バイトを割り振るが、終了前に２５６バイトを解放する場合、関数は、１２８０の「持続時間」を有するとして示されるであろう。
[0388] （ａ）実行の単位は、割り振られるメモリである。これは、それらの中で実行される割振りのサイズを占めるとして関数を表示するであろう。
[0389] （ｂ）実行の単位はメモリの変化である。これは、関数に遭遇するときと対照的に、関数が終了されるとき割り振られるメモリの差をとるとして関数を表示するであろう。従って、例えば、関数が、割り振られた１０２４バイトで入力され、関数が別の５１２バイトを割り振るが、終了前に２５６バイトを解放する場合、関数は、１２８０の「持続時間」を有するとして示されるであろう。
【0227】
[0390] 所与の呼出しスタックレベルの場合、メモリの変化としての上記実行の単位等の表現は、それらが負であることが可能であるため、例えば時間又は消費電力等の他とは異なる。各実施態様の要件に応じて、これは、以下に限定されるものではないいくつかの方法で処理できる。
[0391] （ａ）負数を、通過した０実行単位として示すこと。
[0392] （ｂ）負数を、経過した実行単位の絶対値として示すこと（従って、正の１００単位及び負の１００単位は、同じように表示するであろう）。各実施態様の要件に応じて、表示の部分を改変できる。例えば、これらのエントリは赤で表示できる。
[0393] （ｃ）早期のエントリから実行の単位を差し引くこと。例えば、実行の単位が、所与の呼出しスタックレベルについてメモリの変化であり、関数Ａが１０２４バイトを割り振り、Ａによって呼び出された関数Ｂが２５６バイトを割り振るが、１０２４バイトを解放する場合、次いで関数Ｂは表示されず、関数Ａは、割り振られた２５６バイトの「サイズ」を有するであろう。
[0394] （ｄ）後のエントリから実行の単位を差し引くこと。
[0395] （ｅ）実行の単位を、それが生じた場所から差し引くこと。他の実行の単位に帰すことができる実行の単位の場合、負の実行は、それが加えられた点から差し引くことができる。例として、割り振られたメモリの変化の実行単位を使用するとき、割振りはメモリ使用量の正の変化であり、フリー（ｆｒｅｅ）はメモリの負の変化である。フリーは負であり、それが生じた場所がフリーの割振り点である。この実行の単位を用いて呼出しスタックグラフを表示するために使用されるときのこの手法の最終的な結果は、メモリがどこでスタックに割り振られたのかによって、ヒープにメモリの使用を示すことである。このデータが、プログラム終了時に収集される場合、これはプログラムでのメモリリークを示す。早期に収集される場合、これは、プログラムのどのセクションがメモリ使用を担当しているのかを示し、それは総メモリ使用量のパーセンテージ（又は、イベントトレースがプログラムの持続時間全体ではない場合、イベントトレースによって取り込まれるメモリ使用量の部分）を示す。例えば、関数Ａはその関数インスタンスに２つの割振り、つまり１０２４バイトの割振り及び５１２バイトの割振りを有する。後に、関数Ｂは、１０２４バイトの割振りを解放し、いかなるメモリも割り振らず、関数Ａからの５１２バイトの割振りは、絶対に解放されないであろう。結果として、関数Ａは５１２バイトのサイズを有するとして表示され、関数Ｂはまったく示されないであろう。すべてのトレースイベントが記録されるわけではないため、この手法は、すべての割振りが既知でないときにも役に立つ。トレースストリームの対応する割振りを有さない「フリー」は無視できる。
[0396] （ｉ）フリーを対応する割振り点に実際に結び付けるために、特定の実施形態はトレースイベントを後方に検索する。「フリー」に遭遇するとき、解放されたメモリのアドレスが記憶される。アドレスが解放されたアドレスの集合内にある割振りに遭遇するとき、割振りは、設定済みの解放されたアドレスから削除されるが、それ以外の場合無視される。アドレスが解放されたアドレスの集合にない割振りに遭遇するとき、割振りは、実行の単位として使用される。
[0391] （ａ）負数を、通過した０実行単位として示すこと。
[0392] （ｂ）負数を、経過した実行単位の絶対値として示すこと（従って、正の１００単位及び負の１００単位は、同じように表示するであろう）。各実施態様の要件に応じて、表示の部分を改変できる。例えば、これらのエントリは赤で表示できる。
[0393] （ｃ）早期のエントリから実行の単位を差し引くこと。例えば、実行の単位が、所与の呼出しスタックレベルについてメモリの変化であり、関数Ａが１０２４バイトを割り振り、Ａによって呼び出された関数Ｂが２５６バイトを割り振るが、１０２４バイトを解放する場合、次いで関数Ｂは表示されず、関数Ａは、割り振られた２５６バイトの「サイズ」を有するであろう。
[0394] （ｄ）後のエントリから実行の単位を差し引くこと。
[0395] （ｅ）実行の単位を、それが生じた場所から差し引くこと。他の実行の単位に帰すことができる実行の単位の場合、負の実行は、それが加えられた点から差し引くことができる。例として、割り振られたメモリの変化の実行単位を使用するとき、割振りはメモリ使用量の正の変化であり、フリー（ｆｒｅｅ）はメモリの負の変化である。フリーは負であり、それが生じた場所がフリーの割振り点である。この実行の単位を用いて呼出しスタックグラフを表示するために使用されるときのこの手法の最終的な結果は、メモリがどこでスタックに割り振られたのかによって、ヒープにメモリの使用を示すことである。このデータが、プログラム終了時に収集される場合、これはプログラムでのメモリリークを示す。早期に収集される場合、これは、プログラムのどのセクションがメモリ使用を担当しているのかを示し、それは総メモリ使用量のパーセンテージ（又は、イベントトレースがプログラムの持続時間全体ではない場合、イベントトレースによって取り込まれるメモリ使用量の部分）を示す。例えば、関数Ａはその関数インスタンスに２つの割振り、つまり１０２４バイトの割振り及び５１２バイトの割振りを有する。後に、関数Ｂは、１０２４バイトの割振りを解放し、いかなるメモリも割り振らず、関数Ａからの５１２バイトの割振りは、絶対に解放されないであろう。結果として、関数Ａは５１２バイトのサイズを有するとして表示され、関数Ｂはまったく示されないであろう。すべてのトレースイベントが記録されるわけではないため、この手法は、すべての割振りが既知でないときにも役に立つ。トレースストリームの対応する割振りを有さない「フリー」は無視できる。
[0396] （ｉ）フリーを対応する割振り点に実際に結び付けるために、特定の実施形態はトレースイベントを後方に検索する。「フリー」に遭遇するとき、解放されたメモリのアドレスが記憶される。アドレスが解放されたアドレスの集合内にある割振りに遭遇するとき、割振りは、設定済みの解放されたアドレスから削除されるが、それ以外の場合無視される。アドレスが解放されたアドレスの集合にない割振りに遭遇するとき、割振りは、実行の単位として使用される。
【0228】
[0397] これらの異なる実行の単位は、グラフ領域内のすべてのデータがそれに比してレンダリングされる「軸」として使用される。従って、「時間軸」、又は「消費電力軸」、「グラフィックフレーム枠」等を有することができる。
【0229】
[0398] 用語「ピクセル実行単位」は、実行の軸に沿ったピクセルが表す実行の単位のサイズを指す。例えば、軸が時間の単位で２６５であり、２７５でカーソルによって表されるピクセル列が特定の時間範囲をカバーする図２を参照すること。多くの場合、表示には、例えばカーソル２７５を構成する垂直ピクセルのすべて等、ピクセル実行単位に含まれる複数のピクセルがあることに留意されたい。各実施態様の要件に応じて、ピクセル実行単位の軸は水平（例えば図２）又は垂直である場合がある。本書の他の箇所では、具体的な例が、それがピクセル実行単位を指していないことを明示的にしない限り、（例えば、「ピクセルあたり２つ以上の呼出し又は戻り」等の）単一の時間のピクセルに対する参照が、ピクセル実行単位を指す。各実施態様の要件に応じて、ここに説明されることは、１ピクセル実行単位を示しているが、当業者は、複数ピクセルサイズである実施態様を容易に実施できるであろう。また、この手法は、「１ピクセル実行単位」と見なされる。
【0230】
[0399] 各実施態様の要件に応じて、トレースイベントを、例えば図３１Ａでのように、それぞれが別々に要約される１つ以上のサブストリームに割り当てることが有利な場合がある。この場合、要約は必然的に以下を伴うであろう。
（ａ）実行の単位と関連付けられたトレースイベントの受け取られたストリーム内のトレースイベントをサブストリームに割り当てることと、サブストリームごとに、
（ｉ）該サブストリームから、要約されたトレースイベントの複数の集合を作成することと、
（ｉｉ）要約されたトレースイベントの各集合が、複数のサマリレベルのうちの１つと関連付けられ、複数のサマリエントリを表し、
（ｉｉｉ）各サマリエントリが時間範囲と関連付けられ、そのサマリエントリによって表されるイベントのためにトレースイベントシグナチャをマージするシグナチャを含む。
（ａ）実行の単位と関連付けられたトレースイベントの受け取られたストリーム内のトレースイベントをサブストリームに割り当てることと、サブストリームごとに、
（ｉ）該サブストリームから、要約されたトレースイベントの複数の集合を作成することと、
（ｉｉ）要約されたトレースイベントの各集合が、複数のサマリレベルのうちの１つと関連付けられ、複数のサマリエントリを表し、
（ｉｉｉ）各サマリエントリが時間範囲と関連付けられ、そのサマリエントリによって表されるイベントのためにトレースイベントシグナチャをマージするシグナチャを含む。
【0231】
[0400] これが意味することは、各サブストリームが別々に要約されてよく、結果として生じる要約されたデータは、単一のサブストリーム、つまりサブストリームの部分集合だけを表示するために使用できることである。
【0232】
[0401] 特定の実施形態は、順番に各トレースイベントを処理し、「処理」は、トレースイベントを１つ以上のサブストリームに割り当て、次いで関連性のあるサブストリーム（複数可）のトレースイベントを要約することを意味する。特定の実施形態では、要約の前に、タイムスタンプが押されたトレースイベントのストリーム内の各トレースイベントは１つ以上のサブストリームに割り当てられ、次いでそうしたそれぞれのサブストリームが要約される。特定の他の実施形態は、順番にトレースイベントのグループを処理し、「処理」は、トレースイベントのグループを１つ以上のサブストリームに割り当て、次いで関連性のあるサブストリーム（複数可）のトレースイベントのグループを要約することを意味する。
【0233】
[0402] トレースイベントストリームをサブストリームに割り当てるために使用される区別は、以下を含んでよいが、これに限定されるものではない。
（ａ）種類、
（ｂ）呼出しスタックレベル、
（ｃ）スレッド、
（ｄ）アドレス空間、又は
（ｅ）コア。
（ａ）種類、
（ｂ）呼出しスタックレベル、
（ｃ）スレッド、
（ｄ）アドレス空間、又は
（ｅ）コア。
【0234】
[0403] さらに、処理は、ストリームをサブストリームに割り当てること、つまり要約の前、間、又は後に発生する場合がある。各実施態様の要件に応じて、この処理は、ある実行の単位を別の実行の単位に変換することを含む場合があるが、これに限定されるものではない。例として、いくつかのタイムスタンプが押されたトレースイベントは、関数呼出し及び関数戻りについての情報を含んでよく、異なるタイムスタンプが押されたトレースイベントは、メモリ割振りについての情報を含んでよい。処理ステップは、割り振られたメモリの実行の単位でこのデータを関数呼出し及び関数戻りの情報に変えることができる。
【0235】
[0404]呼出しスタックの要約及びレンダリング
[0405] 特定の実施形態は、呼出しスタック及び／又は関数入口／出口情報を以下によって要約し、レンダリングする。
[0406] （ａ）（特定の実施形態では、関数呼出し及び関数戻りのストリームである）スレッドの実行中に発生する呼出しスタックを表すトレースイベントストリームを採取し、呼出しスタックの各レベルを、トレースイベントの独自のストリームに分割する（及び／又は割り当てる）こと。特定の実施形態は、第１のトレースイベントを任意の呼出しスタックレベルでの始まりとして採取することによって呼出しスタックをレベルに分割し（及び／又は割り当て）、各呼出し又は戻りの結果、それぞれ、将来の呼出しスタックトレースイベントを帰す呼出しスタック深さをインクリメント又はデクリメントする。このプロセスを後方に行うとき、方向は前方の逆であり、従って、関数呼出しトレースイベントは呼出しスタックレベルカウンタをデクリメントするはずであり、関数戻りトレースイベントは、呼出しスタックレベルカウンタをインクリメントするはずであることに留意されたい。
[0407] （ｂ）各呼出しスタックレベルあたりのトレースイベントストリームが、次いで要約される。
[0408] （ｃ）呼出しスタックをレンダリングするために、レンダリングエンジンは、要約された各呼出しスタックレベルをとり、それを、画面上のその呼出しスタック深さの相対的な位置で、画面にレンダリングする。例えば、上部で最も浅いレベルを有する呼出しスタックを、画面の下方でより深いレベルをレンダリングする場合、次いで特定の実施形態は、最初に最も浅いレベルをレンダリングし、次いで画面上でそのすぐ下方の次により深いレベルをレンダリングし、同様にこれを繰り返す。
[0405] 特定の実施形態は、呼出しスタック及び／又は関数入口／出口情報を以下によって要約し、レンダリングする。
[0406] （ａ）（特定の実施形態では、関数呼出し及び関数戻りのストリームである）スレッドの実行中に発生する呼出しスタックを表すトレースイベントストリームを採取し、呼出しスタックの各レベルを、トレースイベントの独自のストリームに分割する（及び／又は割り当てる）こと。特定の実施形態は、第１のトレースイベントを任意の呼出しスタックレベルでの始まりとして採取することによって呼出しスタックをレベルに分割し（及び／又は割り当て）、各呼出し又は戻りの結果、それぞれ、将来の呼出しスタックトレースイベントを帰す呼出しスタック深さをインクリメント又はデクリメントする。このプロセスを後方に行うとき、方向は前方の逆であり、従って、関数呼出しトレースイベントは呼出しスタックレベルカウンタをデクリメントするはずであり、関数戻りトレースイベントは、呼出しスタックレベルカウンタをインクリメントするはずであることに留意されたい。
[0407] （ｂ）各呼出しスタックレベルあたりのトレースイベントストリームが、次いで要約される。
[0408] （ｃ）呼出しスタックをレンダリングするために、レンダリングエンジンは、要約された各呼出しスタックレベルをとり、それを、画面上のその呼出しスタック深さの相対的な位置で、画面にレンダリングする。例えば、上部で最も浅いレベルを有する呼出しスタックを、画面の下方でより深いレベルをレンダリングする場合、次いで特定の実施形態は、最初に最も浅いレベルをレンダリングし、次いで画面上でそのすぐ下方の次により深いレベルをレンダリングし、同様にこれを繰り返す。
【0236】
[0409] 呼出しスタックグラフのリサイジングを行うとき、呼出しスタックレベルがレンダリングされる位置が調整されてよく、呼出しスタックレベルの中でさえ、表される呼出しスタックの異なる部分が画面上の異なる位置にレンダリングされ得ることに留意されたい。詳細については、上記の呼出しスタックのリサイジングに関する項を参照すること。
【0237】
[0410] 呼出しスタックを生成するために使用されるトレースイベントは、切れ目を有する場合がある。つまり、呼出しスタック情報を表すトレースイベントが、切れ目の点でどのようにして互いに関係するのかを判断するための十分な情報がない。切れ目は、２つの所与のトレースイベント間のどこかであり、実施態様の要件に応じて、瞬間又は時間の範囲である場合がある。これが起こる場合がある多くの方法があり、該方法は以下を含むが、これに限定されるものではない。
[0411] （ａ）ｌｏｎｇｊｍｐ、例外（例えば、Ｃ＋＋の例外）、又は従来、介在する呼出しスタック深さのそれぞれを通して戻りコードを実行しない任意の数の呼出しスタック深さを排除する制御フローの他の変化。切れ目は、未知数の呼出しスタック深さがターゲットで排除されていることであり、従って後方に処理するとき、それがより深いレベルである可能性があること以外、次のトレースイベントをどの呼出しスタックレベルに帰すべきであるのかが明確でない。前方に処理するとき、同じ問題が存在するが、次の呼出しスタックレベルはより浅い可能性がある。
[0412] （ｂ）割込み、例外ハンドラ、ＯＳスケジューラ、又は現在のスレッドコンテキストを捨て、その点まで直接的に戻らないコード実行の他の方法をとる、又はそれらから戻ること（その同じコードは、潜在的にその同じ呼出しスタック深さで再び実行されてよいが、それは、その点に戻るためにそれの前にコードを実行する必要がある）。
[0413] （ｃ）トレースストリーム自体が、すべての関数呼出し／関数戻りの情報を含んでいない。例えば、これは、トレースイベントストリームがなんらかのデータを見逃している場合（例えば、ハードウェアトレースシステムで生成されるデータが多すぎることにより生じるＦＩＦＯオーバフローにより、一部のデータが捨てられる／失われる等）に起こる場合がある。
[0411] （ａ）ｌｏｎｇｊｍｐ、例外（例えば、Ｃ＋＋の例外）、又は従来、介在する呼出しスタック深さのそれぞれを通して戻りコードを実行しない任意の数の呼出しスタック深さを排除する制御フローの他の変化。切れ目は、未知数の呼出しスタック深さがターゲットで排除されていることであり、従って後方に処理するとき、それがより深いレベルである可能性があること以外、次のトレースイベントをどの呼出しスタックレベルに帰すべきであるのかが明確でない。前方に処理するとき、同じ問題が存在するが、次の呼出しスタックレベルはより浅い可能性がある。
[0412] （ｂ）割込み、例外ハンドラ、ＯＳスケジューラ、又は現在のスレッドコンテキストを捨て、その点まで直接的に戻らないコード実行の他の方法をとる、又はそれらから戻ること（その同じコードは、潜在的にその同じ呼出しスタック深さで再び実行されてよいが、それは、その点に戻るためにそれの前にコードを実行する必要がある）。
[0413] （ｃ）トレースストリーム自体が、すべての関数呼出し／関数戻りの情報を含んでいない。例えば、これは、トレースイベントストリームがなんらかのデータを見逃している場合（例えば、ハードウェアトレースシステムで生成されるデータが多すぎることにより生じるＦＩＦＯオーバフローにより、一部のデータが捨てられる／失われる等）に起こる場合がある。
【0238】
[0414] これらの切れ目は、トレースストリームをどの呼出しスタックレベルに帰すべきかを決定することを困難にする。つまり、前方に要約するとき、呼出しスタックのどのくらい多くのレベルが削除されたのか、従って次のトレースイベントをどのくらい多くのより浅い呼出しスタックレベルに帰すべきなのかを知ることはつねに可能ではない。後方に要約するとき、呼出しスタックのどのくらい多くのレベルが加えられたのか、従って次のトレースイベントをどのくらい多くのより深い呼出しスタックレベルに帰すべきなのかを知ることはつねに可能ではない。各実施態様の要件に応じて、特定の実施形態は、切れ目の点で（おそらく切れ目の前及び／後に）呼出しスタックを再構築してよい。これは、切れ目の点で呼出しスタック全体を決定することを意味する場合もあれば、それは切れ目の点で呼出しスタックの一部分を再構築することを意味する場合もある。
【0239】
[0415] 特定の実施形態は、この問題を解決する以下の手法の１つ又はなんらかの組合せを利用する。
[0416] （ａ）コンピュータシステムの実行によるトレースストリームの生成は、どのくらい多くのレベルが切れ目で加えられる及び／または削除されるのかを再構築するために必要な情報を含めるために修正される。例えば、ｌｏｎｇｊｍｐにより生じる切れ目で、トレースイベントを後方に処理する特定の実施形態は、ｌｏｎｇｊｍｐが発生する直前の点での呼出しスタックを記述するトレースイベントを出力するようにターゲットを修正する。前方にトレースイベントを処理する他の実施形態は、ｌｏｎｇｊｍｐが発生した直後の点での呼出しスタックを記述するトレースイベントを出力するようにターゲットを修正する。特定の実施形態は、関数入口又は関数出口でスレッドあたりのカウンタをインクリメント又はデクリメントすることによって呼出しスタック深さを追跡する。これを解決する別の手法は、ｌｏｎｇｊｍｐが削除した呼出しスタックのレベルの数を出力することである。さらに別の方法は、スレッドの実行中のさまざまな点で呼出しスタック深さを加えることである。
[0417] （ｂ）加えられる及び／又は削除される呼出しスタックレベルの数は、コード実行での所与の点について静的に決定される。
[0418] （ｉ）例えば、例外ハンドラが呼出しスタック内のすべてのエントリをつねに削除する場合、次いで前方に処理し、このトレースイベントに遭遇するとき、呼出しスタックレベルは最も浅いレベルにレベルをリセットできる。
[0419] （ｉｉ）別の例として、所与の例外ハンドラがつねに既知の深さで呼び出される場合、次いで後方に処理し、このトレースイベントに遭遇するとき、呼出しスタックレベルは、この既知の深さにセットできる。
[0420] （ｃ）トレースイベントは、呼出しスタック深さを明確に決定することが可能になるまで、切れ目の点から走査することができ、次いでトレースイベントは、正しい呼出しスタックレベルに割り振ることができる。例えば、後方に要約し、例外ハンドラからの戻りに遭遇するとき、ハンドラを終了したときの深さが既知ではない場合がある。その時点の前のトレースイベントは、例外ハンドラの開始が決定され、次いで戻りの点での呼出しスタック深さが既知となるまで走査できる。
[0421] （ｄ）コンピュータシステムの実行によるトレースストリームの生成は、現在の呼出しスタック深さについての周期的な表記を含むように修正される。例えば、特定の実施形態では、タイマが開始するたびに、それが現在の呼出しスタック深さをトレースイベントストリームに出力するように、タイマはセットアップされる。上記手法と結合され、これは、正しい呼出しスタックレベルを決定できる前に走査しなければならないトレースデータの量を抑制する。
[0422] （ｅ）コンピュータシステムの実行によるトレースストリームの生成は、現在の呼出しスタックについての周期的な表記を含むように修正される。例えば、特定の実施形態では、タイマが開始するたびに、それが現在の呼出しスタックを含む情報の一部又はすべてをトレースイベントストリームに出力するように、タイマはセットアップされる。上記手法と結合され、これは、正しい呼出しスタックレベルを決定できる前に走査しなければならないトレースデータの量を抑制する。
[0423] （ｆ）呼出しスタックの要約は、切れ目の点で終了され、新しい呼出しスタック要約ストリームが開始される。これをレンダリングするために、レンダリングエンジンは、複数の異なる呼出しスタック要約を、それらが次々出現する単一のコヒーレントなビューにつなぎ合わせるように修正される必要がある。
[0424] （ｇ）呼出しスタックの要約は一時停止され、一時的な新しい要約が切れ目で始められる。切れ目点での深さが決定されるとき、次いで新規に要約されたデータが一次呼出しスタックにマージされ、一時的な要約されたデータは削除され、呼出しスタックの要約は一時停止を解除される（つまり、それは再開する）。レンダリングエンジンの特定の実施形態は、元の要約されたデータとつなぎ合わされた、一時的な要約されたデータを単一のコヒーレントビューに表示してよい。特定の実施形態は、データがマージされるとき、元を示すために切り替わってよい。
[0416] （ａ）コンピュータシステムの実行によるトレースストリームの生成は、どのくらい多くのレベルが切れ目で加えられる及び／または削除されるのかを再構築するために必要な情報を含めるために修正される。例えば、ｌｏｎｇｊｍｐにより生じる切れ目で、トレースイベントを後方に処理する特定の実施形態は、ｌｏｎｇｊｍｐが発生する直前の点での呼出しスタックを記述するトレースイベントを出力するようにターゲットを修正する。前方にトレースイベントを処理する他の実施形態は、ｌｏｎｇｊｍｐが発生した直後の点での呼出しスタックを記述するトレースイベントを出力するようにターゲットを修正する。特定の実施形態は、関数入口又は関数出口でスレッドあたりのカウンタをインクリメント又はデクリメントすることによって呼出しスタック深さを追跡する。これを解決する別の手法は、ｌｏｎｇｊｍｐが削除した呼出しスタックのレベルの数を出力することである。さらに別の方法は、スレッドの実行中のさまざまな点で呼出しスタック深さを加えることである。
[0417] （ｂ）加えられる及び／又は削除される呼出しスタックレベルの数は、コード実行での所与の点について静的に決定される。
[0418] （ｉ）例えば、例外ハンドラが呼出しスタック内のすべてのエントリをつねに削除する場合、次いで前方に処理し、このトレースイベントに遭遇するとき、呼出しスタックレベルは最も浅いレベルにレベルをリセットできる。
[0419] （ｉｉ）別の例として、所与の例外ハンドラがつねに既知の深さで呼び出される場合、次いで後方に処理し、このトレースイベントに遭遇するとき、呼出しスタックレベルは、この既知の深さにセットできる。
[0420] （ｃ）トレースイベントは、呼出しスタック深さを明確に決定することが可能になるまで、切れ目の点から走査することができ、次いでトレースイベントは、正しい呼出しスタックレベルに割り振ることができる。例えば、後方に要約し、例外ハンドラからの戻りに遭遇するとき、ハンドラを終了したときの深さが既知ではない場合がある。その時点の前のトレースイベントは、例外ハンドラの開始が決定され、次いで戻りの点での呼出しスタック深さが既知となるまで走査できる。
[0421] （ｄ）コンピュータシステムの実行によるトレースストリームの生成は、現在の呼出しスタック深さについての周期的な表記を含むように修正される。例えば、特定の実施形態では、タイマが開始するたびに、それが現在の呼出しスタック深さをトレースイベントストリームに出力するように、タイマはセットアップされる。上記手法と結合され、これは、正しい呼出しスタックレベルを決定できる前に走査しなければならないトレースデータの量を抑制する。
[0422] （ｅ）コンピュータシステムの実行によるトレースストリームの生成は、現在の呼出しスタックについての周期的な表記を含むように修正される。例えば、特定の実施形態では、タイマが開始するたびに、それが現在の呼出しスタックを含む情報の一部又はすべてをトレースイベントストリームに出力するように、タイマはセットアップされる。上記手法と結合され、これは、正しい呼出しスタックレベルを決定できる前に走査しなければならないトレースデータの量を抑制する。
[0423] （ｆ）呼出しスタックの要約は、切れ目の点で終了され、新しい呼出しスタック要約ストリームが開始される。これをレンダリングするために、レンダリングエンジンは、複数の異なる呼出しスタック要約を、それらが次々出現する単一のコヒーレントなビューにつなぎ合わせるように修正される必要がある。
[0424] （ｇ）呼出しスタックの要約は一時停止され、一時的な新しい要約が切れ目で始められる。切れ目点での深さが決定されるとき、次いで新規に要約されたデータが一次呼出しスタックにマージされ、一時的な要約されたデータは削除され、呼出しスタックの要約は一時停止を解除される（つまり、それは再開する）。レンダリングエンジンの特定の実施形態は、元の要約されたデータとつなぎ合わされた、一時的な要約されたデータを単一のコヒーレントビューに表示してよい。特定の実施形態は、データがマージされるとき、元を示すために切り替わってよい。
【0240】
[0425] 呼出しスタックグラフに関する要約システムの最後の目標は以下の通りである。
[0426] （ａ）呼出しスタックグラフにスレッドの実行履歴の視覚化を表示し、複数の関数呼出しが、表示装置上での１ピクセル実行単位により表される時間範囲で所与の呼出しスタックレベルの中で発生するとき、該ピクセル実行単位に第１の色を割り当て、該第１の色が、該複数の関数呼出しのそれぞれと関連付けられる。
[0427] （ｉ）これを行う複数の手法がある。例えば、他の箇所に説明されるように、ピクセル実行単位の色は、関数の基本的な色のブレンドとなるであろう。しかしながら、色は、発生している関数呼出しの数の表示である場合もあるであろう（実施形態は、例えば１０以下の場合緑、１０００以下の場合青、及び１０００を超える場合赤等のスケールを使用できるであろう、又は実施形態は、ピクセル実行単位の中での実行の単位の数に比してスケールを使用でき、これが、事実上、ピクセル実行単位あたりの呼出しの密度を示すであろう。別の手法は、異なる色を示すために、ピクセル実行単位の軸以外の軸を使用し、複数の色を使用することであろう。実施形態は、最高で３つの色を示すための空間を有する可能性があり、そのピクセルの中にあるあらゆる３つの関数の色を示すであろう。
[0428] （ｂ）複数の関数呼び出しのそれぞれは、対応する色と関連付けられ、第１の色は、該第１の色が複数の関数の色のブレンドを含むという点で、該複数の関数呼出しのそれぞれと関連付けられる。
[0429] （ｉ）これは、本書の他の箇所に説明される、どの色をレンダリングするのかを決定するために、ピクセル実行単位の中にある特定の関数に割り当てられる色を混合する手法である。
[0426] （ａ）呼出しスタックグラフにスレッドの実行履歴の視覚化を表示し、複数の関数呼出しが、表示装置上での１ピクセル実行単位により表される時間範囲で所与の呼出しスタックレベルの中で発生するとき、該ピクセル実行単位に第１の色を割り当て、該第１の色が、該複数の関数呼出しのそれぞれと関連付けられる。
[0427] （ｉ）これを行う複数の手法がある。例えば、他の箇所に説明されるように、ピクセル実行単位の色は、関数の基本的な色のブレンドとなるであろう。しかしながら、色は、発生している関数呼出しの数の表示である場合もあるであろう（実施形態は、例えば１０以下の場合緑、１０００以下の場合青、及び１０００を超える場合赤等のスケールを使用できるであろう、又は実施形態は、ピクセル実行単位の中での実行の単位の数に比してスケールを使用でき、これが、事実上、ピクセル実行単位あたりの呼出しの密度を示すであろう。別の手法は、異なる色を示すために、ピクセル実行単位の軸以外の軸を使用し、複数の色を使用することであろう。実施形態は、最高で３つの色を示すための空間を有する可能性があり、そのピクセルの中にあるあらゆる３つの関数の色を示すであろう。
[0428] （ｂ）複数の関数呼び出しのそれぞれは、対応する色と関連付けられ、第１の色は、該第１の色が複数の関数の色のブレンドを含むという点で、該複数の関数呼出しのそれぞれと関連付けられる。
[0429] （ｉ）これは、本書の他の箇所に説明される、どの色をレンダリングするのかを決定するために、ピクセル実行単位の中にある特定の関数に割り当てられる色を混合する手法である。
【0241】
[0430]追記
[0431] 本明細書の特定の図は、方法及びシステムを示すフローチャートである。これらのフローチャートの各ブロック、及びこれらのフローチャート内のブロックの組合せが、コンピュータプログラム命令によって実施されてよいことが理解される。これらのコンピュータプログラム命令は、マシンを作り出すためにコンピュータ又は他のプログラム可能装置にロードされてよく、これによりコンピュータ又は他のプログラム可能装置上で実行する命令は、フローチャートの１つ又は複数のブロックで指定される関数を実装するための構造を作成する。また、コンピュータ又は他のプログラム可能装置に特定の方法で機能するように命令できるこれらのコンピュータプログラム命令は、コンピュータ可読メモリに記憶されてよく、これによりコンピュータ可読メモリに記憶される命令は、フローチャートの１つ又は複数のブロックに指定される関数を実装する命令構造を含む製造品を作り出す。また、コンピュータプログラム命令は、一連の操作ステップをコンピュータ又は他のプログラム可能装置上で実行させて、コンピュータ又は他のプログラム可能装置上で実行する命令が、フローチャートの１つ又は複数のブロックで指定される関数を実装するためのステップを提供するようにコンピュータ実装プロセスを作り出すために、コンピュータ又は他のプログラム可能装置上にロードされてもよい。
[0431] 本明細書の特定の図は、方法及びシステムを示すフローチャートである。これらのフローチャートの各ブロック、及びこれらのフローチャート内のブロックの組合せが、コンピュータプログラム命令によって実施されてよいことが理解される。これらのコンピュータプログラム命令は、マシンを作り出すためにコンピュータ又は他のプログラム可能装置にロードされてよく、これによりコンピュータ又は他のプログラム可能装置上で実行する命令は、フローチャートの１つ又は複数のブロックで指定される関数を実装するための構造を作成する。また、コンピュータ又は他のプログラム可能装置に特定の方法で機能するように命令できるこれらのコンピュータプログラム命令は、コンピュータ可読メモリに記憶されてよく、これによりコンピュータ可読メモリに記憶される命令は、フローチャートの１つ又は複数のブロックに指定される関数を実装する命令構造を含む製造品を作り出す。また、コンピュータプログラム命令は、一連の操作ステップをコンピュータ又は他のプログラム可能装置上で実行させて、コンピュータ又は他のプログラム可能装置上で実行する命令が、フローチャートの１つ又は複数のブロックで指定される関数を実装するためのステップを提供するようにコンピュータ実装プロセスを作り出すために、コンピュータ又は他のプログラム可能装置上にロードされてもよい。
【0242】
[0432] 従って、フローチャートのブロックは、指定された関数及び指定された関数を実行するためのステップの組合せを実行するための構造の組合せをサポートする。フローチャートの各ブロック、及びフローチャートのブロックの組合せが、指定された関数若しくはステップ、又は特殊目的ハードウェア及びコンピュータ命令の組合せを実行する特殊目的ハードウェアベースのコンピュータシステムによって実装できることも理解される。
【0243】
[0433] 例えば、Ｃ、Ｃ＋＋、Ｃ＃（ＣＳｈａｒｐ）、Ｐｅｒｌ、Ａｄａ、Ｐｙｔｈｏｎ、Ｐａｓｃａｌ、ＳｍａｌｌＴａｌｋ、ＦＯＲＴＲＡＮ、アセンブリ言語等の任意の数のコンピュータプログラミング言語が、本発明の態様を実施するために使用されてよい。さらに、例えば手続きオブジェクト指向技術又は人工知能技術等のさまざまなプログラミング手法が、各特定の実施態様の要件に応じて利用されてよい。コンピュータシステムによって実行されるコンパイラプログラム及び／又はバーチャルマシンプログラムは、概してより高いレベルのプログラミング言語を変換して、プログラムされた関数又は関数の集合を実行するために１つ以上のプロセッサによって実行されてよい機械命令の集合を生成する。
【0244】
[0434] 上記説明では、特定の実施形態は、特定のデータ構造、好ましい及び任意選択の基準、好ましい制御フロー、及び例の観点から説明される。説明される方法の他の及び追加の応用は、当業者による応用の検討後に理解されるであろうように、本発明の範囲内にある。
【0245】
[0435] 用語「機械可読媒体」は、コンピュータシステムの要素によって読み取られてよいデータを提供することに関与する任意の構造を含むと理解されるべきである。そうした媒体は、不揮発性媒体、揮発性媒体、及び伝送媒体を含むが、これに限定されるものではない多くの形をとってよい。不揮発性媒体は、例えば光ディスク又は磁気ディスク、及び（ソリッドステートドライブ、つまりＳＳＤ等の）フラッシュメモリに基づいたデバイス等の他の持続性のメモリを含む。揮発性媒体は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）及び／又はスタティックランダムアクセスメモリ（ＳＲＡＭ）を含む。伝送媒体は、プロセッサに結合されたシステムバスを含むワイヤを含む、ケーブル、ワイヤ、及びファイバを含む。機械可読媒体の共通の形式は、例えば及び制限なくフロッピーディスク、フレキシブルディスク、ハードディスク、ソリッドステートドライブ、磁気テープ、任意の他の磁気媒体、ＣＤ－ＲＯＭ、ＤＶＤ、又は任意の他の光媒体を含む。
【0246】
[0436] 図５６は、例示的な実施形態と一致するシステム及び方法が実装されてよい例示的なネットワーク化された環境５６３０を示す。示されるように、ネットワーク化された環境５６３０は、サーバ（５６００）、クライアント（５６２０）、及びネットワーク（５６１０）を制限なく含んでよい。図５６に示される例示的な簡略化された数のサーバ（５６００）、クライアント（５６２０）、及びネットワーク（５６１０）は、特定の実施態様で必要に応じて修正できる。実際には、追加のサーバ（５６００）、クライアント（５６２０）、及び／又はネットワーク（５６１０）があってよい。
【0247】
[0437] 特定の実施形態では、クライアント５６２０は、有線接続及び／又は無線接続を介してネットワーク５６１０に接続し、それにより直接的に又は間接的にのどちらかでサーバ５６００と通信してよい、又はサーバ５６００と結合されてよい。代わりに、クライアント５６２０は、任意の適切な有形コンピュータ可読媒体又は（例えばディスクドライブ、ＣＤ－ＲＯＭ、ＤＶＤ等の）データストレージデバイス、データストリーム、ファイル、又は通信チャネルを通してサーバ５６００と関連付けられてよい。
【0248】
[0438] ネットワーク５６１０は、各特定の実施態様の要件に応じて、公衆携帯電話網（ＰＬＭＮ）、電話網（例えば、公衆交換電話網（ＰＳＴＮ）及び／又は無線ネットワーク）、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、広域ネットワーク（ＷＡＮ）、インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）ネットワーク、プライベートネットワーク、インターネット、イントラネット、セルラーネットワーク、及び／又は他の種類の適切なネットワークを制限なく含んでよい。
【0249】
[0439] ネットワーク化された環境５６３０の１つ以上の構成要素は、ネットワーク化された環境５６３０の１つ以上の他の構成要素によって実行されているとして説明されるタスクのうちの１つ以上を実行してよい。
【0250】
[0440] 図５７は、サーバ５６００の態様又はクライアント５６２０の態様等の本発明の特定の実施形態の態様を実施するために使用され得るコンピューティングデバイス５７００の例示的な図である。特定の実施形態では、コンピューティングデバイス５７００は、制限なくデスクトップコンピューティングデバイス若しくはノートブックコンピューティングデバイス、又は制限なくスマートフォン若しくはタブレットデバイスを含んでよいモバイルコンピューティングデバイスであってよい。コンピューティングデバイス５７００は、バス５７４０、１つ以上のプロセッサ５７５０、メインメモリ５７１０、読出し専用メモリ（ＲＯＭ）５７２０、ストレージデバイス５７３０、１つ以上の入力装置５７８０、１つ以上の出力装置５７７０、及び通信インタフェース５７６０を制限なく含んでよい。バス５７４０は、コンピューティングデバイス５７００の構成要素間での通信を可能にする１つ以上の導体を制限なく含んでよい。
【0251】
[0441] プロセッサ５７５０は、任意の種類の従来のプロセッサ、マイクロプロセッサ、又は命令を解釈し、実行する処理論理回路を制限なく含んでよい。メインメモリ５７１０は、ランダムアクセスメモリ（ＲＡＭ）又はプロセッサ５７５０による実行のための情報及び命令を記憶する別の種類のダイナミックストレージデバイスを制限なく含んでよい。ＲＯＭ５７２０は、従来のＲＯＭデバイス、又はプロセッサ５７５０による使用のための静的な情報及び命令を記憶する別の種類のスタティックストレージデバイスを制限なく含んでよい。ストレージデバイス５７３０は、磁気記録媒体及び／又は光学記録媒体及びその対応するドライブを制限なく含んでよい。
【0252】
[0442] 入力装置（複数可）５７８０は、ユーザが、例えばキーボード、マウス、ペン、スタイラス、手書き文字認識、音声認識、生体認証機構、タッチスクリーン等のコンピューティングデバイス５７００に情報を入力できるようにする１つ以上の従来の機構を制限なく含んでよい。出力装置（複数可）５７７０は、ディスプレイ、プロジェクタ、Ａ／Ｖ受信機、プリンタ、スピーカ等を含む、ユーザに情報を出力する１つ以上の従来の機構を制限なく含んでよい。通信インタフェース５７６０は、コンピューティングデバイス５７００が、他のデバイス及び／又はシステムと通信できるようにするトランシーバ状の機構を制限なく含んでよい。例えば、通信インタフェース５７６０は、例えば図５６に示されるネットワーク５６１０等の、ネットワークを介して別のデバイス又はシステムと通信するための機構を制限なく含んでよい。
【0253】
[0443] 本明細書に詳細に説明されるように、コンピューティングデバイス５７００は、例えばデータストレージデバイス５７３０等の別のコンピュータ可読媒体から、又は通信インタフェース５７６０を介して別のデバイスからメモリ５７１０に読み込まれてよいソフトウェア命令に基づいた動作を実行してよい。メモリ５７１０に含まれるソフトウェア命令は、プロセッサ５７５０に、他の箇所に説明されているプロセスを実行させる。代わりに、配線で接続される回路網は、本発明と一致するプロセスを実施するために、ソフトウェア命令の代わりに又はソフトウェア命令と組み合わせて使用されてよい。従って、さまざまな実施態様は、ハードウェア回路網とソフトウェアの任意の適切な組合せに制限されない。
【0254】
[0444] 当業者は、本発明の実施形態が、直接ポイントツーポイントデータ通信システム、ダイヤルアップネットワーク、パーソナルイントラネット若しくは企業イントラネット、独占ネットワーク、又はインターネットへの接続を有する若しくは有さないこれらのいずれかの組み合わせを制限なく含む任意の適切なデータ通信ネットワークを使用してよい。
【0255】
[0445] 図５８は、本発明の特定の実施形態の態様を実装するために使用されてよいネットワーク化されたコンピューティングシステム５８４０の例示的なブロック図である。図５８に示されるネットワーク化されたコンピューティングシステム５８４０は、コンピューティングシステム５８３５、データソース５８３０、及びコンパイル／デバッグコンピュータ５８０５に結合されたネットワーク５８２５を含む。コンパイル／デバッグコンピュータ５８０５は、大量記憶装置５８００、マルチメディアデバイス５８５５、入出力装置、及び（双方向通信リンク５８４５を介してネットワーク５８２５に結合される）インタフェース５８５０、１つ以上の中央処理装置（例えば、５８１０）、メモリ５８１５、及びダイナミックコンパイル及び／又はデバッグシステム５８２０を含む。単一のコンピューティングデバイスで実装又は複数のコンピューティングデバイス間で分散されてよい上述の構成要素に関する詳細は、本書を通じて説明される。
【0256】
[0446] 上記説明は多くの詳細を含み、特定の例示的な実施形態が説明され、添付図面に示されているが、そうした実施形態が、幅広い発明を示すにすぎず、幅広い説明に対して制限的ではないこと、及び上述したように、さまざまな他の変形形態が当業者の頭に思い浮かぶ場合があるので、本発明が、示され、説明された具体的な構造及び配置に制限されていないことが理解されるべきである。本発明は、本明細書に開示される異なる種類及び／又は実施形態からの要素の任意の組合せ又はサブコンビネーションを含む。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23A】
【図23B】
【図23C】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30A】
【図30B】
【図31A】
【図31B】
【図31C】
【図31D】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37A】
【図37B】
【図37C】
【図37D】
【図38A】
【図38B】
【図38C】
【図39】
【図40】
【図41】
【図42】
【図43】
【図44】
【図45】
【図46】
【図47】
【図48】
【図49】
【図50】
【図51】
【図52】
【図53】
【図54】
【図55】
【図56】
【図57】
【図58】
