カスタムinstrumentsのモデリング

(音楽)

(拍手) ありがとう (拍手) Performance Tools Engineerの チャド･ウルフです ここではCustom Instrumentsの モデリングについて話します Custom Instrumentsのモデリングは modeler内で行われます そのmodelerの役割は OSに記録される生のイベントの推測 変換の実行や 表示可能なイベントの作成 Air Instruments UI内の Instruments用に 他のmodelerを 入力することなどです このアーキテクチャについては― “Creating Custom Instruments” という昨年のセッションで触れています 今回は中央の modelerと呼ばれる部分に注目します modelerはTime Profilerを含め すべてのInstrumentsにとって重要です Time Profilerでは UIに表示されたデータは カーネルに記録されたものと 同じではありません 変換にはmodelerを使います カーネルはスレッドがしていることの サンプルを得る際 プリミティブバックトレースを作成 または取得し time-sampleテーブルに入れます time-profiler modelerに 拾い上げられ― より表示可能な形式の バックトレースに変換されます time-profileテーブルへ移動し― 最終的にTime ProfilerのInstrumentsで 表示されます プリミティブバックトレースを 捉えるほうが簡単で効率的なのです その後 modeler内の ユーザ空間で修正もでき― カーネル内の記録が 非常に効率的にできます カーネルは別の形でも 最適化を行えます 前回から移動していないスレッドを サンプリングする際は― 完全なバックトレースではなく プレースホルダを置きます それをtime-profiler modelerが拾い 既知のバックトレースを持ち出し Instrumentsによって表示された time-profileテーブルに複製します これはカーネルの記録バッファの容量を 大幅に節約します スレッドがアイドル状態の際は 特にです UIも効率的に保てます UIはプレースホルダのことを 知る必要がないからですが それはすべてがmodelerにより 正規化されているからです この話は何度も出てきます Custom Instrumentsの複雑さを モデリングレイヤに吸収させる話です ロジックの中に埋め込む追跡コードや Instrumentsで使用するUIなど 他の領域で単純化を促進します 今日は モデリングの基本を いくつか見て― Custom Modelerを ビルドするプロセスを説明します 一からCustom Modelerを作成するのは 難しい場合があります 今年のセッションでは サンプルコードを用意したので modelerのための基礎としても 使えます その過程で 実行と CLIPSのルールエンジンについてや― “投機”という 重要なトピックにも触れます まずはモデリングの基本を見ましょう

modeler作成時は他のアーキテクチャも 定義する必要があります Instruments内で すべてを結びつける スキーマを定義し 最終的にInstrumentsの出力を 表示します それらはInstrumentsの 配信パッケージに組み込まれており Instruments内部にインストールし 試すことができます Xcodeにプロジェクトを１つ セットアップしていると仮定します ここでしたいのは Custom Modelerの追加です 今年 添付したサンプルコードから 作業しても― プロジェクトを セットアップしておくことはできます Custom Modelerの作成が 必要なのはいつか？ Xcodeがmodelerを 生成することもあります 入力としてos signpostを使う時は 特にです これらのmodelerは Instrumentsを素早く動かすためで Custom Modelerでできることを 開示するためにあるわけではありません 複数の入力テーブルのデータの 融合などが― Custom Modelerでは可能です ワーキングメモリの維持も重要です 累計合計の維持や オープンインターバルの追跡 ワーキングメモリを使い さらに広範囲な計算を実行できます

Instrumentsが 自然には作成しないグラフも作れます modeler内での データの統合も可能です 移動平均や高度なカルマンフィルタも 計算できるかもしれません 使い方次第ですが Custom Modelerで実現できるのです 最終目標は より賢いInstrumentsを ビルドし― Instrumentsがコード内の事象を 把握することです そのコードで作業する人が トラブルシューティングの前に Instrumentsに着目するのが理想です そうすれば 新たなことに時間を割けます modelerは 基本的にはルールエンジンで― 一連の入力テーブルと出力テーブルに 結びつけられています Instrumentsの分析コアは入力テーブルを 時間順に並べるタスクを引き受け それらをmodelerの ワーキングメモリに注入します メモリ内のオブジェクトは “ファクト”と呼ばれます メモリの変化やファクトについて 推論するには― CLIPS言語で ルールシステムを定義します CLIPSは80年代からあるため 始めやすいオープンソース言語です 私たちのサンプルコードや 今日のスライドにもよい例があります modelerが出力したいものを 見つけた時― modelerには出力テーブルに書き込む 関数があります modelerを書き始めるには ３段階のプロセスがあります まず何をモデル化したいかを 決めること Custom Instrumentsの作成技術を 理解していることが前提です Custom Instrumentsのインフラの 最大の活用方法も同様です 2019年の“Developing a Great Profiling Experience”では― Custom Instrumentsを使ったコードの 話をしています モデル化を理解するなら そこから始めるといいでしょう modeler用に定義された出力があるなら 次は入力が必要ですが コードからInstrumentsに入力するには os signpost APIを通すのが一番です このAPIはコードで起きていることを 広範囲に追跡し 引数データを渡して input streamでの推論を可能にします 次はルールシステムを定義し ルールの書き込みを始めましょう ステップ２と３は 繰り返しになるので 前に戻り Signpostの追加や 変更の必要性が生じても 問題なく対応できます Signpostはコードで起きていることと Instrumentsの間に境界を形成します そのため Signpostの呼び出しに コメントをし― 変更するとInstrumentsが壊れることを 周知してください このプロセスは実例を見れば よく分かると思います モデリングのエキスパート アレハンドロの話を聞いてください

(拍手) こんにちは ありがとう チャド チャドが強調していた 思考プロセスについてですが 例を見れば 要素が どう組み合わさるか分かります デモアプリケーションから 始めましょう 今まで取り組んだ中で 最もクールな仕事かもしれません ヤギのリストですが アプリケーションに ただ表示されているわけではありません リストをソートできます ソート機能は モバイルエージェントパターンを使用 これは他のパターンと 多くの類似点があります futureやpromise operationのキューもそうです モバイルエージェントという言葉を 耳にしたら― ご自身が使っているパターンに 置き換えて考えてみてもいい 今回はモバイルエージェント パターンに限って話します このパターンの名前のとおり モバイルエージェントは重要な概念です 左上にモバイルエージェントを 円にして視覚化します ソートでは タスクを 複数に分割することを目的とします 例えば初期リストをソートし 結果を書き留める際― 各サブタスクは “ストップ”上で実行されます ストップはエージェントに 実行コンテキストなどを提供します モバイルエージェントパターンを 使用した実装方法を見てみましょう 左上の“ソート”をクリックすると エージェントは 最初のストップに移動します この場合 ストップのホストはUIで リストを取得する 最初のサブタスクを実行します リストが得られたら 例えばDispatch Queueがホストする 別のストップに移動できます そして実際のソートは この時点で実行されるのです ソートが完了したら UIに戻ることができ― ソートされた結果を リストに追加します 最後は再び使えるよう ソートボタンに戻ります パターンとエージェントには 主なフェーズが２つあると言えます ストップ上で実行されているか そこへ移動している場合もありますが それらの持続時間や 相互作用には興味が湧きます インターバルを客観的にし ソートの例をもう一度 見てみます スペースが必要なので このデバイスは左側へ ソートをクリックするとエージェントは UIストップに移動します 次にインターバルを確認します 説明的な文字列や 何が起きたかという知らせです ストップ上ではエージェントが 最初のサブタスクを実行しリストを取得 ここで異なるインターバルが 確認できます

次にエージェントが Dispatch Queueに移動すると それ自体のインターバルで表されます

Dispatch Queueでは エージェントがソートを実行 ソートモードで実行しているのが 分かります それがUIストップに戻り 最終的なインターバルが決まり― ストップではソート結果を リストに入力するサブタスクを実行 インターバルの始まりは アクティビティが始まった時間で― 終わりはアクティビティの 終了時間と考えられます このインターバルを念頭に Instrumentsの入手と設計が可能です それが こちらです 最上部に複数のインターバルがあり 異なる動きや実行を見ることができます 最上部のトラックの下には追跡中に アクティブだったストップがあります Instrumentsの視覚的側面に加え 詳細ビューも見たいと思います 各ストップで何が起きたかを 詳細に確認できます 開始時刻や所要時間 エージェントの情報などです ここで 一番上の列に 注目しましょう この列で関心のある事柄を 定義できるのです この画面では開始時刻や時間 エージェントの種類ですが 一般的にこれらの列をInstrumentsの パッケージファイルで指定します そして これらの列は 出力テーブルをまとめて形成しますが 私たちはこれらを使い 保存したいものを定義します そこでモデル化したいものが何かを 決めるという初期目標を達成します 次はアプリケーションから Instrumentsへのデータ取り込みです os signpostを使って遂行します インターバルを再び見ましょう こちらです os signpostを利用するAPIは インターバル用にビルドされています ここで さらに一歩進め event Signpostを使用します 各event Signpostはインターバル間の 境界で発せられます その理由は― Signpostの放出量を約50％ 節約できるからだけではありません モバイルエージェントパターンより 正確な表現なのです アクティビティを終えたエージェントは すぐに別のものを始めますが 次に進むことを示すSignpostの発行は １つで済みます

そのために モバイルエージェントの クラスに実行停止機能があります ストップ上で何かを行うという 内部ロジックを実行する前には 特定のsignpostIDと メッセージのあるSignpostがあります 次の停止機能へ向かう際も 同種のos signpostの設定があり エージェントを次のストップに 移すというロジックを実装しています モバイルエージェントと同様に 移動の前には適切にタイトルをつけ 別のsignpostIDと メッセージを与えます

今は この真ん中のmodelerに 注目しましょう これはアプリケーションに入れた Signpostを― 出力テーブルに表示させる 有用なインターバルに変換します これはmodelerの例です アプリケーションの状態を知らないため ワーキングメモリは空白です しかし modelerは os signpostテーブルと密接に作用し os signpostテーブルは既出の アプリケーションから生成されます modelerがモバイルエージェントの 検出を試みているとしましょう ソートをクリックすると modelerはos signpostを受け取り modelerはファクトによって Signpostを表します os signpostの呼び出しに従い ファクトはスロットが埋められています os signpostのファクトは モバイルエージェントの情報を宣伝 modelerはエージェントを推論するため そのファクトを使用し ファクトを主張することで ワーキングメモリに導入します ここではバックグラウンドに移動した エージェントがあると主張しています

次にmodelerは 時間と同様に エージェントのアクティビティを 判断します モバイルエージェントの移動については modelerもすでに知っており Signpostのファクトから 開始は42秒だと判断 42秒で始まったことを ワーキングメモリへ伝え modelerが再認識することもできます この時点でSignpostのファクトは 消えますが 関連情報はワーキングメモリに 保存しているので問題ありません スペースが必要なので 少し上に動かします 最後にmodelerがアクティビティの 全インターバルを決定します 今は開始時間だけで インターバルの全容は分かりません しかし このデモアプリケーションは 別のSignpostを発しています modelerが受け取ると それをファクトとして表示します インターバル間の境界で出されるよう Signpostを構成していたので modelerは 別のSignpostを受け取ると それまで開いていたインターバルの ファクトを閉じることができます この場合 modelerはファクトから これらの値を調べ― 余裕をもって 完全なインターバルを決定します そのために 出力テーブルを召喚し― 開いたインターバルのファクトと 完全なインターバルとを取り替えます この場合はバックグラウンドに移し 出力テーブルを作成します

さて… CLIPSコードについて 掘り下げる前に アプリケーションコードからの APIの呼び出しが CLIPS内のファクトに どう変換されるか理解しましょう os signpostを 特定の名前で呼び出すと os signpostファクトで 同じ名前のスロットになります

この場合はイベントですが Signpostのタイプが― os signpostファクト内の event-typeスロットになります 最終的にはSignpostIDが os signpostファクト内の 識別子の値になり 埋め込んだメッセージも同じく os signpostファクト内の メッセージの値になります

モバイルエージェントを検出する CLIPSで書かれたルールです これは まずos signpostの存在を 検出しようとします “Mobile Agent Moved”のような 特定の名前です このインスタンス変数の 識別子スロット内の値を取得します

メッセージを構文解析し 有用な情報を抽出することもできます

ここで示したい条件がもう１つ Signpostが識別した モバイルエージェントの不在の照合です モバイルエージェントを識別しても 重複するものは持ち出したくありません モバイルエージェントがない場合に 実行を限定します インスタンス変数で 識別されていてもです その場合 modelerは先に進み― モバイルエージェントを ワーキングメモリにアサートできます

モバイルエージェントがしたことを 検出したい時― いくつかのプロパティを決定するため os signpostのファクトと照合します でも今回 knotキーワードは使用していません ワーキングメモリ内で エージェントを生かしたいからです 解析済みのエージェントを使えば もっと色々なことができます これら２つのファクトがあると― 動きのファクトを アサートしたりできるので modelerはエージェントの活動を 追跡できるようになります

エージェントの活動を検出するため CLIPSコードをどう書くかを見ましたが modelerの基礎となる実行について もう少し詳しく知る必要があります 再びチャドを呼び ルールの実行について話してもらいます (拍手) ルールエンジン内のCLIPS言語での ルール実行について説明しましょう CLIPSでルールを定義する時は プロダクションオペレータにより LHSとRHSに分けられます LHSは言語を説明する部分のため ここでルールエンジンに見つけてほしい パターンを定義します LHSのパターンを満たす一連の ファクトをルールエンジンが特定すると アクティベーションを作り出します 次に このアクティベーションごとに RHSのルールが放出されます RHSは言語の命令的な部分です retractのような機能にアクセスし ファクトを削除することもできますし アサートにより ファクトを ワーキングメモリに追加したりできます 特別な機能を用い modelerの 出力テーブルに書き込みもできます

では ファクトについて少し話を アサート関数を使い ファクトを ワーキングメモリにアサートすると 新しいファクトに ファクトアドレスが割り当てられます 小文字のfとダッシュの後に 数字がついて識別されます ワーキングメモリ内のファクトを 修正したい時は専用の機能を使い ワーキングメモリ内の ファクトアドレスとスロットを取ります これは撤回とアサーションの 組み合わせとして実装されています ワーキングメモリのファクトを取り消し 変更を加え― 更新されたフィールドやスロットを用い ワーキングメモリに再アサートします これが重要なのは― 再アサートがルールをいくつか再適用し 再アクティベートするからです この機能はよく使います ルールシステムは そうやって ワーキングメモリを変化させるからです 論理ループのように複雑なケースに 発展する場合もあります コードに誤って論理ループが 作成された例を考えてみましょう ここにある小さなルールでは― モバイルエージェントの インスタンス数を数えられます 最初はスロットがゼロの カウンタのファクトから始まります メモリ内の各モバイルエージェントには RHSのルールが放出され― 単純にスロットを１つ上げることで カウンタを変更します 簡単に聞こえますが 実行すると どうでしょうか ワーキングメモリ内は ゼロの初期カウントから始まります どこかでモバイルエージェントが アサートされるとしましょう RHSを放出するのに LHSは十分な状態です それが修正用の関数を呼び 最初にファクトを取り消します カウント値を増やして変更し― ワーキングメモリに 再アサートします 同じルールが再び放出されたのが 分かるでしょうか 同じモバイルエージェントに ２ ３ ４ ５ ６ ７と数え… 追跡が停止するまで続けていきます これは致命的なエラーであり ルールエンジンの異常を告げています Instruments Inspector内の modelerのコンソールには ループ中に発生した全イベントと アクティベーションが示されています デバッグの方法が分かるのです 最も簡単な方法は “目標指向プログラミング”です カウンタのファクトを 直接 修正する代わりに ゴールのファクトを作成し カウンタにバンプさせます 今度はモバイルエージェントの インスタンスを検出した時に それをカウントする ゴールのファクトをアサートします 私たちのカウントルールで カウンタとゴールを捉えますが カウンタにバンプさせたため ゴールを撤回します それがルールの繰り返しを避け 論理ループから抜け出す方法です ルールの実行順序について 説明しましょう modelerの結果が どう変わるかも見てみます 実行停止機能の話に戻りましょう モバイルエージェントが 実行される直前です os signpostを見て気づくのが 最初のバージョンのコードの引数です エージェントの型と文字列を 使用しています ここではSorting Agentか― トレースバッファにログインするため 約14バイトのデータが必要です 文字列からタイプコードに変えれば 改善できそうです ４バイトの整数になるだけで １イベントで10バイトを節約できます これが何千という単位だと考えれば― 追跡バッファ内で 何万バイトも節約できます そのためにはmodeler内で マッピングを作成し コードを文字列に変換し そのためのファクトを使用します 今回は検出ルールで エージェントのタイプコードを取得し symbol sentinelとなるスロットと共に モバイルエージェントをアサートします 完全な文字列は まだ設定できていません sentinelを持つモバイルエージェントは ２つ目のルール内で検出し― 先ほどのスライドで見たような 相応のタイプコードを見つけます これら２つのピースを入手したら kindのスロットを― symbol sentinelから 実際の文字列に変更します このデザイン全体が― アサート直後に放出するという ２番目のルールに依存しています ではエージェントが待機するなど 別ルールがあった場合は？ これはモバイルエージェントを参照し kindのスロットを使用した場合です アサートとルックアップルールの間に 入り込んだ場合は？ 一種のsentinelを見ることに これはルールシステムへの変更なので 新たなバグを抱えかねません 回避するには ルールに制限を追加することです kindがsentinelと同等でない限り ルールの放出を遅らせ― エージェントのkindが リアルなものに変わるまで制限します しかし sentinelにならないと 仮定するルールがすでにある場合 これは全ルールに適用されるので メンテナンスの問題になり得ます 代替案も見てみましょう 目的はアサート直後に ルックアップルールを放出することです １つの方法がCLIPSに こう指示することです 顕著なルールはデフォルトの顕著性が ゼロのものより重要だと そのルールがシステム内で 最も顕著である限り― 最初のルールが終われば ２番目のルールがすぐに放出します 他の場所が顕著だとコードを調べて 100が最高値かを確かめる必要がある しかし それは別の話です ルールの順序と実行を制御するには もう少し直接的な方法もあります そのためにアクティベーションについて 少し学びましょう 基本的にアクティベーションは― パターンのLHSを満たす ファクトの組み合わせです 各アクティベーションのため ルールのRHSを放出します しかし すぐには放出せず― 代わりにアクティベーションを データ構造に記録します これがアジェンダと 呼ばれるもので―

ワーキングメモリの更新から生じた アクティベーションのリストです ルールエンジンはリストの 最上段から下に進み― 特定のパターンで ルールを放出すればいい 最初のルールを放出後 次に下りてきました データ構造は動的なので このルール99がファクト17を撤回すると ファクト17が これら２つの アクティベーションに参照されます CLIPSは先に進む前に これらのアクティベーションを撤回し 実行が再開されると アジェンダはこのようになります アジェンダは顕著に 順序づけられているので ここで顕著性が 重要になってくるというわけです しかし より重要なのはmodeler上に 単一のアジェンダがない点です 実際は定義されたモジュールごとに あります いくつかの標準モジュールを定義し 分析コアで利用してみましょう まずはmodelerモジュール 純粋な推論ロジックと推論ルールを このモジュールに入れたいところです ルール名の前に “MODELER::”をつけます recorderモジュールと呼ばれる ２番目のモジュールを定義しました 出力用の書き込みルールの前に “RECORDER::”をつけます こうする理由は これらのルールを実行する時― modelerのアジェンダを すべて最初に実行できるからです これはrecorderモジュールに 完全に移動するまで続きます こんな時は自信も持てます 出力用の書き込みルールがあれば modelerモジュールで推論されている ワーキングメモリを見る必要はない CLIPSでカスタムモジュールを定義し 利用することもできます ルックアップルールを より適切に実行する方法を見ましょう まず ルックアップモジュールのために モジュールを定義することは避けたい 今度は“LOOKUP::”を先頭につけ モジュール内にルールを敷きます モバイルエージェントのファクトを アサート後は― ルックアップアジェンダに集中するよう すぐにCLIPSに指示します modelerのアジェンダに戻る前に アクティベーションを実行し― 次のモデル化ルールを実行 これは実行の間にルールを スリップさせる最高の方法です 情報を得られたら デバッグとプロファイリングを 開始する方法を見ましょう アレハンドロに戻ってきてもらい 話をしてもらいます (拍手) ありがとう チャド これらのモデルをビルドして利用できる デバッグなどについて話します まず ロギングから ロギングのプリミティブは printfとよく似ています フォーマット文字列や フォーマットフラグを指定できたり 型を表現したい変数も指摘できます しかし通常のprintfとは異なり Instruments Inspectorで ログ状態を動的に有効― または無効にできます ロギング状態を任意のルールに 取り込むには？ CLIPSの log-narrativeという機能です printf同様に文字列 “Resolve agent kind code”を特定 ％でフォーマットタイプや エンジニアリングのタイプ― “string”を指定し それに変数が続きます

ここでもInstruments Inspectorで 様々なプリミティブを有効にし― プリミティブにより特定のルールが 何度 放出されたかを見られます 時間分布も同様です ルールのアクティブ化に費やした時間を 秒や％で確認できます コンテキストはさておき デモに戻り― 連携について説明します

ダウンロード可能な サンプルコードです 様々なターゲットが使用できます まずは“Plot Templates Modeling”を 見ましょう これをビルドし実行すると Instrumentsが開きます

ビルドは成功したようです

Instrumentsを開けます ヤギのアプリケーションが すでにプルアップされています 画面を最大化せずにおきます まずは ブランクのテンプレートを開きます 右上で追加したいInstrumentsを 選択できます そのために ここへ モバイルエージェントターゲットを 探しましょう

Instruments Inspector経由で log-narrativeは無効にもできます “コマンド＋I”で Instruments Inspectorを開く デフォルトで “None”と設定されています “Narrative”に切り替え log-narrative状態を有効に これは閉じ ヤギのリストの アプリケーションに切り替えます

記録を始めます ここでは異なるヤギをソートできます Instrumentsの中に アクティビティが現れました もう一度 クリックすると さらに表示されます 目的を説明するには これで十分です ズームインし 別のインターバルを表示します 先述したアクティベーションなどの インターバルです 実際のlog-narrativeを見るため 再びInstruments Inspectorを開くと modeler logテーブルが 現れています すべてのlog-narrative状態が 生きる場所です このResolving agent kindコードも そうです ルール内の他のものに追加されました

log-narrativeを使用し プロファイルに切り替えます このログインタブでは profile 1などへの切り替えができます Instruments Inspectorを閉じ Instrumentsをもう一度 実行 追跡を記録し直します モバイルエージェントから アクティビティが発生している可能性が やはり説明には十分ですね Instruments Inspectorを もう一度 開きます 表示するlog-narrativeがなく modeler logテーブルはもうありません ここで このmodelerのタブに 移動すると― 異なるプロファイリング値を 見渡せます このルールには 未知のストップがあり― 所要時間がエントリと ％で表示されています モデリングで指定した他のルールも 確認できます

最後に面白いことに気づきました 捉えたいので 追跡を再び実行します ソートを始め 異なるアクティビティの出現を待ちます でもオレンジ色の長いインターバルが ファクトの後に出てきました 期待した同時の記述や レンダリングには従っていないようです 理由があります その説明と 解決策を見つけるために― チャドを再び呼びましょう

(拍手) ありがとう アレハンドロ 彼が見せてくれた現象を理解し 回避するために― “投機”と呼ばれる概念を 紹介します まず なぜ長いインターバルが 出現したか 数秒間にわたって現れ 広がったりしました しかし本当の問題は― これらの記録がmodelerの ワーキングメモリにしかないことです UIはmodelerの出力テーブルを見ており インターバルを見られません いつ閉じるのかも分からないので 出力テーブルに書き込むこともできない それが先ほどのケースです できればmodelerの出力テーブルに プレースホルダのような行を書きたい そのために導入したのが “投機モード”です modelerの投機モードに― “出力テーブルに書き込む 最後の機会だ”と言われたとします 例を見てみましょう event horizonと呼ばれる白線まで modelerが全データを処理しました event horizon以降は modelerが表示されません これは追跡が終わったから 起きたことなのか― 分析コアが追跡部分を 埋められていないのかは分かりません 行の反対側に何があるかは謎です バックグラウンドに移るインターバルを 作ったのは分かりますか？ 実行中のSignpostのペアの間で うまく押さえられている証拠です しかし追跡中のインターバルが どこで終わるか分からないのは 終了イベントが event horizonの反対側にあるからです 投機モードに入った際は UIのためにプレースホルダのイベントを テーブルに書き込むだけにしたい インターバルは実行中のSignpostから 現行のevent horizonまで実行します modelerは 投機モードになっています ワーキングメモリに注入される 投機的なファクトを得られるからです recorderのルールでは 投機とインターバルの ファクトを組み合わせ― event horizonのタイムスタンプを使い インターバルをテーブルに書き込めます オープンなインターバルが 書き込めるのです ルールの例を見てみましょう まず投機的な出力の書き込みルールを recorderのモジュールに入れる 頭に“RECORDER::”をつけます 投機イベントでマッチングし event horizonの値を捉えます インターバルには 理論上の終了時間があります オープンなインターバルファクトに対し RHSを放出します event horizonに基づく終了時間から 時間を計算します 始点はインターバルの開始時間です そして通常の出力ルールと同じように 新しい行を作成し 列に記入します 投機的な出力の記述ルールで 唯一 違うのは― 投機的なファクトに基づき ルールを試行及び予測している点です 通常 出力テーブルに書き込むのは クローズしたインターバルです そして 即時モードでは 記録用のヘッドが前方へ向かい― 古い投機的データは削除されます そして modelerは 再び投機モードに入り― 投機イベントを元に戻すことができ UIは通常どおり更新を続けます 追跡が停止すると modelerは 再度 投機モードに入ります しかし いかなる記述内容も 追跡データに保存され― UIだけでなく 下流のmodelerでも利用可能になります 既存のInstrumentsに その変更を加えると― このように動き始めます モバイルエージェントの追跡が続き 停止中のインターバルが進行します 更新はリアルタイムです 下を見ると継続時間が増え続けてますね 記録を終了すると インターバルがずれるのが分かります これは追跡の一部として記録され 保存されます Custom Modelerは時間の節約と 技術の習得に大いに役立ちます Custom Instrumentsを最大限に活用し 知性を加えましょう 知性あるInstrumentsは 優れたユーザ体験をもたらします

さらなる情報やサンプルコードは デベロッパWebサイトでご確認を これで終わります ありがとうございました (拍手)