必要条件

この記事に必要な予備知識

このチュートリアルを最大限に活用するには、まず、Adobe Scoutファーストステップガイドを参照してください。

ユーザーレベル

中級

原文 作成日: 2013/1/28

Accurate profiling with Adobe Scout

Adobe Scoutを使用し始めた瞬間から、膨大な量のデータにアクセスできるようになります。ActionScriptの実行から、Flash Playerが実行する個々のレンダリングステップに至るまで、コンテンツのほとんどすべての側面について、データを得られるようになります。すぐにでもコンテンツのパフォーマンスの問題を見つけ出したいと思うでしょう。しかしその前に重要なのは、そうしたデータがどのように収集されるかを理解することです。

Flash PlayerがScoutに送信する各データにはコストがかかります。コンテンツを実行することに加えて、Flash Playerは自らを測定し、そのデータを送信することにも、時間をかける必要があります。つまり、Scoutでプロファイリングを行うとき、Flash Playerは通常とは異なった動作をします。どのようなデータを収集対象として選択するかによって、その動作の違いがわずかになるか、大きくなるかが決まります。その違いが受け入れ可能になるかどうかは、あなたが答えを得ようしている質問によって決まります。

この記事では、Flash Playerがどのようにデータを測定し、Scoutに送信するか、また、あなたがどのように収集するデータを決定するかを説明します。この記事は、コンテンツの動作やパフォーマンスについての質問に、より正確な答えを得るために役立つでしょう。Scoutで表示される数字の意味をより深く理解することで、より自信を持ってプロファイリングを行えるようになります。

この記事がScoutのユーザーインターフェイスのガイドではないことに注意してください。Scoutの使用方法、様々なパネルの機能が分からない場合は、まず、ファーストステップガイドを参照してください。

ScoutでFlash Playerからデータを取得する

Scoutを使用し始めてまず気付くのは、Flashコンテンツを読み込むとすぐに、新しいセッションが開き、データが到着し始めることです。このデータは Telemetryと呼ばれています。基本的には、Flash Playerがコンテンツの実行中に作成する一連の測定値です。Telemetryを使用するために、Scoutは、目的のデータを送信するようにFlash Playerに指示できる必要があり、Flash Playerは、Scoutに接続してそのデータを送信できる必要があります。

どのようにScoutはデータを送信するようにFlash Playerに指示するのか

ホームディレクトリに .telemetry.cfgというファイルがあります。そのファイルをScoutは使用して、Flash Playerに何をするかを指示します。このファイルには、Scoutが動作しているマシン、使用しているポート、Flash Playerが収集するデータ(つまり、Scoutの「 Settings for New Sessions」で選択した内容)について情報が保存されています。Flash Playerと同じマシン上でScoutを実行している場合、このファイルに対する操作はまったく不要です。あなたがいずれかの設定を変更するたびに、Scoutがこのファイルにその変更を書き込み、Flash Playerが新しいSWFを読み込むたびにこのファイルを読み取ります。セッションが既にScoutで開始されていたら、設定を変更することはできません。それらの設定は新しいセッションにのみ適用されます。

別のマシンでScoutを実行し、そのScoutにFlash Playerがデータを送信するようにしたい場合は、 .telemetry.cfgファイルを手動で設定する必要があります。その方法については、ファーストステップガイドで説明しています。このファイルで指定した同じポートをリッスンするようにScoutを設定する必要があることを忘れないでください。ポートはScoutのPreferencesダイアログボックスで設定できます。

モバイルデバイスでAdobe AIRコンテンツのプロファイリングを行う場合は、Scout Companion AppのiOS版Android版Kindle版を該当するApp Storeからダウンロードできます。このアプリケーションはScoutのインスタンスに接続し、Scoutと通信して、どのデータ設定が選択されているかを調べます。このプロセスでは .telemetry.cfgは使用されません。代わりに、Scout Companion Appは、Adobe AIRの動作中のインスタンスにこの情報を中継します。これにより、そのインスタンスはScoutに送信するデータとその送信先が分かります。

どのようにFlash PlayerはScoutにデータを送信するのか

Telemetryが有効になっている(つまり、 .telemetry.cfgファイルがホームディレクトリにある)場合、Flash Playerは、新しいSWFを読み込むたびに、ScoutへのTCP接続を開こうとします。接続に失敗した場合、Flash PlayerはTelemetryを無効にして、処理を続行し、コンテンツにはプロファイリングのオーバーヘッドはまったく発生しません。接続に成功した場合、Flash PlayerはScoutへのデータのストリーミングを開始し、その処理は新しいセッションとして表示されます。データは、AMFと呼ばれる圧縮バイナリ形式で送信され、Scoutによって表示前に解析されます。FLMを保存すると、実際には、Flash Playerが送信した元のデータを、同じバイナリ形式で保存することになります。つまり、FLMを開くと、Scoutはコンテンツから受信したデータを再生するだけで済み、しかもそれは高速に行われます。

収集するデータを決定する

ScoutがFlash Playerから受信する各データにはコストがかかります。要求するデータが多くなるほど、Flash Playerが実行する必要のある処理が増えます。また、コンテンツのパフォーマンスへの影響も大きくなります。このため重要になるのは、収集するデータを決定するために答えるべき質問の種類を考えることです。それにより、「Settings for New Sessions」(図1参照)でどのチェックボックスをオンにするかが分かります。

測定対象をパフォーマンスにする場合、収集対象を低オーバーヘッドのデータである「 Basic Telemetry」、「 ActionScript Sampler」、および「 CPU Usage」カテゴリに制限する必要があります。これらのカテゴリのデータは慎重に設計されているため、Flash Playerは、コンテンツの実行と比べて、できるだけ時間をかけないで、データの収集とScoutへの送信を行うことができます。つまり、Scoutに表示される時間測定値は信頼できます。時間測定値はパフォーマンスの問題を見つけ出すために不可欠です。

詳細情報をレンダリングについて収集する場合は、高オーバーヘッドの設定である「 DisplayList Rendering Details」と「 Stage3D Recording」を選択することもできます。これらの設定は、グラフィックス関連の問題をデバッグするには非常に便利です。フレームごとに描画されるDisplayObjectと、実行されるStage3Dコマンドの正確な順序をそれぞれ確認できます。しかし、このレベルの詳細情報を得ようとすると、コストが犠牲になります。Flash Playerははるかに長い時間をかけて、データを収集してScoutに送信する必要があり、それにより、コンテンツが遅くなります。このデータを収集することにした場合、Scoutに表示される時間情報は正確でなくなります。一部の実行時間は実際のものよりも長く表示されます。Flash Playerが実行する処理が増えるためです。それだけではなく、結果は 偏ったものになります。一部のアクティビティが他のものよりも詳細に測定されるためです。

正確なパフォーマンスデータが必要な場合は、オーバーヘッドを低く保つことを忘れないでください。詳細な描画データと正確な時間測定値を同時に得ることはできません。例えるなら、ウサイン・ボルト選手が100メートルを走っている最中にインタビューしようとするようなものです。あなたがボルト選手にマイクを向けている間、彼は世界記録を破ることはありません。

Basic TelemetryとActionScript Sampler

パフォーマンスに関心があるときは、「Basic Telemetry」および「ActionScript Sampler」設定を有効にする必要があります。それらの設定では実際、2種類のデータが収集されますが、最初はそれらのデータに少し混乱することがあります。Flash Playerがコンテンツを実行するときに、次の2つの中核部分が連携します。

  1. Flash Player。実際の処理を実行し、外部の世界との橋渡し役を果たします。他のタスクの間で、Flash Playerは画面にレンダリングし、サウンドとビデオを再生し、入力イベントとネットワーク操作を処理します。
  2. SWF。基本的には、画像のような静的リソースと、スクリプトやタイムラインのような動的なリソースの集まりです。こうした動的なリソースは、Flash Playerによって実行され、Flash Playerに何をするかを指示します。

Flash Playerのコードベースは計測されるため、主要な場所で自らを測定することになります。具体的には、コードの主要なブロックの実行にかかっている時間、その主要なデータ構造によって使用されているメモリを測定します。ここでのキーワードは「主要な」です。Flash Playerがすべての関数ごとにかかる時間を測定した場合、オーバーヘッドは非常に高くなり、動作はプロファイリング前より、はるかに遅くなります。長時間かかることが分かっているアクティビティのみを測定するため、それらの測定のオーバーヘッドは無視できる程度です。つまり、Scoutで表示される時間はできる限り正確になります。このデータは Basic Telemetryと呼ばれ、ScoutによってFrame Timelineの描画、Summaryパネル、Activity Sequenceパネル、Top Activitiesパネルで使用されます。Flash Playerは実行時間が5マイクロ秒より長いアクティビティのみをレポートすることに注意してください。これより短いアクティビティはScoutには表示されません。

Scoutには、SWF内のActionScript 3の実行についての情報も表示されます。この情報をActionScriptパネルで確認できるのは、「ActionScript Sampler」設定を有効にしているときです。このデータは「Basic Telemetry」とは大きく異なります。Flash Playerは、コードが何かが前もって分からないため、事前に計測できません。Flash Playerが各関数のコールを記録してScoutに送信した場合、データは正確になりますが、オーバーヘッドは高くなりすぎます。代わりに、Flash PlayerはActionScriptの実行中にサンプリングを行います。1ミリ秒ごとに、コールスタックのスナップショットを作成します。スナップショットは、コードが特定のタイミングで実行していたことを表します。

ScoutのActionScriptパネルで、このデータは、選択した範囲のフレームにわたって集計され、各関数に平均でかかっている時間の割合が表示されます。このデータは近似値にすぎません(サンプリングに基づいて計算されているため、最近似のミリ秒数です)。しかし、表示されるサンプルの数が多いほど(例えば、選択するフレームが多くなるほど)、精度は高くなります。ActionScriptパネルでは、常にデータの品質指標に注意する必要があります。赤い悲しい顔のアイコン(図2参照)は、結果が統計的に有意になるためにはサンプルの数が不足していることを示します。一方、緑のスマイルアイコン(図3参照)は、サンプルの数が十分であることを示します。ここでは、どの関数のコストが最も高いかを判断するためのデータが十分であることを示しています。

計測とサンプリングの違いを理解することが非常に重要なのは、これらの2種類のデータの精度が異なるためです。ジェットコースターに乗って、走行時間を測定するとしましょう。まず、 計測の手法では、ストップウォッチを持って、走行が始まったらストップウォッチを開始し、走行が終わったらストップウォッチを停止します(図4参照)。これにより、かなり正確な結果(例えば、最近似の秒数)が得られます。しかし、ストップウォッチの開始と停止、各測定値の記録に時間がかかっています。走行ごとにこの計測を行う場合、テーマパークでの一日は少し長くなります(一度に1回の計測を行うと仮定)。この例では、23秒という測定値を得られたとします。

一方、サンプリングでは、ストップウォッチを持ち運びません。代わりに、カメラを設置して、走行の写真を10秒ごとに(または選択した任意の間隔で)撮ります(図5参照)。煩わしさは減ります。ストップウォッチを持ち歩いて測定を行う手間がないためです。ただし、精度は下がります。走行が終わった後、走行の写真の数を調べて(この例では2枚)、その数に写真間の時間間隔(この例では10秒)を掛けます。これにより、20秒という近似値を走行時間として得られます。

サンプリングは計測よりも精度は低くなります。しかし、繰り返す回数が多くなるほど(ジェットコースターの乗車回数が増えるほど)、相対誤差は小さくなります。これは「ActionScript Sampler」の動作に似ています。「写真」はコールスタックのスナップショット(サンプル)に相当し、1ミリ秒ごとに作成されます。

Scoutの便利な機能の1つが、これらの2種類のデータを用途に合わせて組み合わせることができることです。例えば、Flash Playerでマウスイベントを受信するコードが計測され、「Basic Telemetry」に表示されます。これにより、このイベントの処理にかかった時間をマイクロ秒の精度で測定できるようになります。ActionScript 3イベントハンドラーをコードに使用している場合、Flash Playerはコードの実行中にコードのサンプルも収集します。Scoutで、Top Activitiesパネルに移動し、イベントをクリックすると、ActionScriptパネルがフィルターされ、その特定のイベントの処理中に実行されていたコードのみが表示されます(図6参照)。

「Basic Telemetry」と「ActionScript Sampler」のデータはSummaryパネルでも組み合わせて使用できます。このパネル内のデータのほとんどは、「Basic Telemetry」からのデータです。しかし、「ActionScript Sampler」を有効にした場合は、「ActionScript」カテゴリを展開して、最も長い時間がかかっているパッケージの内訳を確認できます。このデータが近似値にすぎないことは忘れないでください。サンプリングに基づいて計算されているためです(Summaryパネル内の残りのデータとは異なります)。こうしたデータは「≈」記号で示されます(図7参照)。

これらの2種類のデータについてまとめると次のようになります。

  • Basic Telemetry(Activity Sequenceパネル、Top Activitiesパネル)では、Flash Playerが実行していることの時間測定値を得られます。このデータは、Flash Playerの低オーバーヘッドの計測により、マイクロ秒の精度で得られます。
  • ActionScript Sampler(ActionScriptパネル)では、ActionScript 3コードが実行していることの定期的なスナップショットを得られます。1ミリ秒ごとにコールスタックのサンプルが取得され、一定期間にわたってデータが集計され、各関数に平均でかかっている時間の割合が表示されます。時間は近似値ですが、選択するフレームの数が多くなるほど精度は上がり、スマイルアイコンが必ず表示されるでしょう。

CPU Usage

CPU Usage」設定を有効にした場合、Flash Playerは使用しているCPU時間を定期的に測定します。オペレーティングシステムに照会してこのデータを取得するため、このデータはOS XのアクティビティモニターまたはWindowsのタスクマネージャーで表示される数値に対応します。このデータは低オーバーヘッドであるため、コンテンツのパフォーマンスを調査中に、この設定を有効にすることができます。

DisplayList Rendering Details

コンテンツでFlash DisplayListを使用する場合、「 DisplayList Rendering Details」設定を使用すると、各レンダリングパスで描画される画面の部分、各DisplayObjectのレンダリングにかかる時間について、詳細情報を記録できます。この情報は、Scoutの DisplayList Renderingパネルで確認できます。特に、「 Heat Map」モードでは、画面のどの部分をレンダリングするために最も長い時間がかかっているかがグラフィカルに表示されます。

このデータを収集するためのオーバーヘッドはDisplayList上のオブジェクトの数によって異なります。この処理はコストが非常に高くなることがあるため、このデータ設定を有効にして、コンテンツの全体的なパフォーマンスを表示しないようにしてください。各DisplayObjectのレンダリングにかかる相対時間のみを表示してください。適切なワークフローを次に示します。

  1. 「Basic Telemetry」のみを有効にしてコンテンツのプロファイリングを行い、DisplayListのレンダリングにかかっている時間を確認し、ActionScriptの実行などの他のアクティビティにかかっている時間と比較します。
  2. DisplayListのレンダリングが問題であれば(時間がかかりすぎているため)、「DisplayList Rendering Details」設定を有効にしてから、もう一度コンテンツのプロファイリングを行います。その後、ScoutのDisplayList Renderingパネルを使用して、問題の原因を特定できます。

Stage3D Recording

コンテンツでStage3Dを直接使用しているか、StarlingやAway3Dなどのフレームワークを介して使用している場合、どのような処理が実行されているかについて、Scoutで詳細情報を表示できます。Flash PlayerではStage3D APIは計測されるため、Stage3D APIのコールとその引数をScoutに送信できます。その後、Scout内でコマンドを再生して、各シーンがどのようにレンダリングされるかを一度に1描画コールずつ確認できます。こうした操作が可能なのは、Stage3DエンジンのコピーがScout自体に組み込まれているためです。

Stage3D Recording」設定を有効にすると、膨大な量のデータが生成され、オーバーヘッドが高くなります。なぜなら、Flash Playerはすべてのバッファー、テクスチャ、AGALプログラムを、Stage3D APIの各関数コールについての詳細情報と共に、Scoutに送信する必要があるためです。これは大量のデータであり、その収集と送信により、コンテンツの実行が遅くなります。レンダリングの問題をデバッグするときに、「Stage3D Recording」を有効にするのは効果的ですが、このデータ設定を有効にして、パフォーマンスのプロファイリングは行わないでください。行おうとした場合、ActionScriptパネルに警告が表示されます(図8参照)。

パフォーマンスに関心がある場合は、次の手順を実行する必要があります。

  1. 「Basic Telemetry」と「ActionScript Sampler」のみを有効にして、コンテンツのプロファイリングを行います。ScoutのSummaryパネルで、「ActionScript」カテゴリを展開し、Stage3D APIにかかっている時間の割合を確認します。ActionScriptパネルでは、どの関数のコールに最も長い時間がかかっているかが表示されます。
  2. コンテンツがStage3D APIにかけている時間が長すぎる場合は、「Stage3D Recording」を有効にすることができます。ScoutのStage3D Renderingパネルで、コンテンツによるStage3D APIの各コールが表示されます。このデータが非常に便利なのは、パフォーマンスの問題の原因を見つける場合です。例えば、発行する描画関数のコールが多すぎる、GPUの状態の変更頻度が高すぎるなどが、原因として見つかります。

レンダリングの問題、例えば、予期したとおりに動作しないAGALプログラムなどをデバッグする必要がある場合は、2番目の手順から開始できます。ただし、忘れないでください。コンテンツのパフォーマンスを改善したい場合は、その最適化を試みる前に、Stage3Dが問題の一部であるかどうかをまず調べてください。

「Stage3D Recording」では、Scoutに送信するデータが多すぎるため、わずか数分で数ギガバイトのメモリを使い果たします。コンテンツをしばらく実行した後に発生するレンダリングの問題をデバッグしたい場合があるため(例えば、レベル22のドラゴンのボスキャラにシャドウが適用されない理由を調べるなど)、Scoutには「 Delayed」という記録モードが用意されています。「Recording」設定を「 Immediate」から「 Delayed」に変更した場合、Flash Playerは変更前と同じ詳細なStage3DデータをScoutに送信しますが、Scoutはそのデータをメモリに読み込みません。Stage3D Renderingパネルで「 Start Recording」をクリックすると、Scoutは必要なデータ(メッシュやテクスチャなど)のみをメモリに読み込みます。これにより、多くのメモリを使用せずに、その時点からコマンドを再生できます。

Scoutで正確なデータを得るためのヒント

ここまでは、なぜ適切なデータ設定を選択することが、Scoutで正確にプロファイリングを行うために重要であるかを説明してきました。しかし、もう1つ重要なのは、プロファイリングを行う環境を考慮することです。考慮しない場合、誤判断につながる可能性が高いデータを得る結果になり、実際には存在しない問題を解決しようと時間を無駄にすることになります。ここでは、Scoutでパフォーマンスのプロファイリングを行うときに考慮するべきいくつかの重要なヒントを示します。

  • Flash Playerのリリースバージョンを使用してプロファイリングを行います。他のバージョン、例えばデバッガーバージョンのパフォーマンス特性は異なります。
  • SWFのリリースバージョンを使用してプロファイリングを行います。SWFのデバッガーバージョンははるかに遅くなります。それらのActionScriptバイトコードは、コンテンツのデバッグに役立つように、詳細に計測されるためです。
  • ユーザーが使用すると予期される同じハードウェア、オペレーティングシステム、ブラウザーを使用してプロファイリングを行います。コンテンツは超高速の開発マシン上では適切に動作できますが、平均的なユーザーのマシン上でそのように動作するとは限りません。
  • プロファイリングの実行中は、他のプログラムやSWFを実行しないでください。そのような実行は、Flash Playerが行う測定を妨げるためです。その結果、誤判断につながる情報がレポートされることがあります。実行中のプログラムはできる限り減らしてください。他のブラウザータブが開いていれば、それらのタブもすべて閉じます。
  • プロファイリングの実行時にはVMwareまたは デバイスエミュレーターは使用しないようにしてください。可能であれば、ネイティブのマシンまたはデバイスを使用してください。そのパフォーマンス特性がユーザーの体験するものに近くなるためです。VMWareをどうしても使用する必要がある場合は、複数のコアを使用するように設定してください。1つのコアしか使用できない場合、VMWareではScoutは適切に機能しません(これは既知の問題)。
  • モバイルでプロファイリングを行う場合、ネットワークに十分な帯域幅が、Flash Playerによるデータの送信用にあることを確認してください。ない場合、ネットワーク接続がボトルネックになり、誤判断につながる情報がScoutに表示されます。

次のステップ

ここでは、より正確かつ効果的にプロファイリングを行えるように、Scoutでデータが収集される方法を説明しました。現在対処中の質問への答えを得るために、必要になるデータのみを収集することを忘れないでください。やみくもにすべてのデータ設定を有効にすると、データは誤判断につながるものになり、無駄なプロファイリングを行った末に、コンテンツを間違って最適化するという結果になります。

パフォーマンスの問題を特定したら、次のステップは、 なぜ問題があり、どのようにその問題に対応するかを決定することです。Flash Playerの仕組みについての詳細、Scoutで表示される情報への対応方法については、Adobe ScoutによるFlash Playerの把握を参照してください。