XNAパフォーマンステストを自動化しますか？

XNAでのパフォーマンステストの自動化について、人々のアプローチや考えはどうなっていたのだろうと思いました。現在、私は2dでのみ作業していると考えていますが、それはさまざまな実装でパフォーマンスを改善できる多くの領域をもたらします。

例としては、空間分割の2つの異なる実装がある場合、1つは別の実装よりも高速かもしれませんが、実際のパフォーマンステストを行わないと、どれが確かにどれであるかを確実に判別できません（コードが明らかに明らかに遅い場合を除きます）。部品）。特定の時間枠で両方の実装のエンティティを追加/更新/削除し続けるユニットテストを作成し、各時間枠で作成された数を確認できます。高い方がより高速になります（この特定の例では）。

もう1つのより高いレベルの例は、60 fpsを下回ることなく、画面上に大まかにいくつのエンティティを表示できるかを確認する場合です。これの問題は、自動化することです。モックゲームを開始し、気になっている部分を純粋にテストして、他のすべてを無効にするために、隠しフォームトリックなどを使用する必要があります。

テストを自動化できたとしても、これは単純な問題ではないことを知っています。実際に結果が十分に優れているかどうかを判断するのは人間次第ですが、ビルドステップの一部として、これらのテストを実行して公開することができます。比較のためのどこかでの結果。

このようにして、バージョン1.1から1.2に移行したが、いくつかの基本的なアルゴリズムを変更した場合、一般にパフォーマンススコアが上がり、アプリケーションの全体的なパフォーマンスが向上し、1.2から1.3に気付く場合があります。その後、全体的なパフォーマンスが少し低下しました。

では、プロジェクトでこの種のことを自動化した人はいますか？そうであれば、パフォーマンス比較を高レベルでどのように測定し、どのフレームワークをテストに使用しますか？ほとんどのパーツでテスト可能/モック可能になるようにコードを記述しているので、パフォーマンス結果を得るためのメカニズムとしてテストを使用できます...

===編集===

わかりやすくするために、XNA内の自動テストを使用してパフォーマンスを追跡する最良の方法に興味を持っています。テストをプレイしたり、マシンでゲームを手動で実行して推測したりするのではありません。これは、ゲームがXハードウェアでプレイ可能かどうかを確認するのとはまったく異なります。ゲームエンジン/フレームワークが変化したときのパフォーマンスの変化を追跡することについてです。

コメントの1つで述べたように、「QuadTreeA内で2秒以内にいくつのノードを挿入/削除/更新できるか」を簡単にテストできますが、結果が変更されたかどうかを確認するために毎回これらの結果を物理的に調べる必要があります。うまく、バージョン間の違いに気づくかどうかを確認するためにそれを再生するだけに頼るよりも優れています。ただし、Assertを挿入して、2秒で5000を下回ると、失敗を通知して失敗を通知する場合は、実装だけでなくハードウェアのコンテキストでもあるため、もろいテストになります。そうは言っても、これらの種類の自動テストは、ある種のビルドパイプラインとしてテストを実行している場合にのみ実際に使用できます。

チェックアウト->ユニットテストの実行->統合テストの実行->パフォーマンステストの実行->パッケージ

したがって、ある種のレポートとして、CIサーバー上のあるビルドから別のビルドへの統計を簡単に比較できます。また、継続的インテグレーションに慣れていない場合、これは誰にとってもあまり意味がないかもしれません。この質問の主な核心は、ビルド間で人々がこれをどのように管理するか、そしてどのようにレポートするのが最善かを知ることです。私が言ったようにそれは主観的である場合がありますが知識は答えから得られるのでそれは価値のある質問のようです。

「実際のゲームを実行する」を完全に排除したいと考えているので、基本的に私の答えは最初から失格です。しかし、おそらくあなたはそれから何かを取り除くことができるので、なぜ私がこれを投稿するのかは関係ありません：

修士論文では、ゲームエンジンのいくつかのモジュールで同じことを達成するために、さまざまな独立した/並列の実装があり、いくつかのパフォーマンス測定を実行する必要があります。技術的には、ゲームを実行して画面上のプロファイラーに表示される数字を見ることだけが妨げになることはありませんが、実装を変更するたびに実行するのは面倒なプロセスであるため、自動化したかったのです。

だから私が持っているのはこれです：

• 対象の関数/スコープの実行にかかった時間を測定するために使用されるスコープ付きプロファイラー（オブジェクトをスタックに置き、構築時にタイムスタンプを取得し、分解時にタイムスタンプを取得）
• 特定の数のプロファイルされたサンプルを保存し、最後のn個のサンプルの平均を単純なテキストファイルにダンプするモジュール
• ゲームの開始、マップのロード、検査対象のモジュール内で使用されるアルゴリズムの変更、プロファイラーダンプファイルのパスの変更、その他多数の操作に使用できるゲーム内コマンドライン。上記のコマンドラインは、実行可能ディレクトリ内の特定の特別なファイルを確認し、そこから取得した文字列を実行するためにロードするように設定されています（非常に粗雑なプロセス間通信の手段として）。

したがって、これにより私ができることは、適切なスクリプト環境（たとえば、バッチスクリプトによるWindowsコマンドプロンプト-実際にはその目的でRubyを使用する）からアプリケーションを起動し、ダンプファイルのパスを設定し、マップをロードして、そのままにすることです数分間実行し、実行中のゲームを終了し、別のダンプファイルパスを設定し、使用するアルゴリズムを切り替え、マップを再度読み込み、すすぎ、繰り返します。Rubyスクリプトは、コマンドラインモジュールが探している特別なファイルを作成し、コマンドラインが理解できる構文に目的のコマンドを配置することで、ゲームと通信します。

現在、このプロジェクトで継続的な統合を実際に使用していませんが、Rubyスクリプトを起動して、生成されたパフォーマンスログを解析し、パフォーマンスが予期せずにCIシステムと通信するxUnit互換XMLを生成することを妨げるものはありません。なんらかの理由で問題が発生し、ビルドサーバーのすべてのフルビルドでスクリプトを実行します。

私のゲームはXNA（それはプレーンなC ++とDirectXです）で書かれていませんし、このアプローチはビルドサーバーで実際にゲームを実行したくないという事実を尊重していません。それはまた、おそらくあなたが望んでいるものほど柔軟ではありません-それでも、それは自動化されたパフォーマンス測定へのすっきりしたローテクなアプローチであり、ある程度CIにやさしいです（ビルドサーバーが頑丈な場合）。

編集： 私が実際にそのアプローチを取った距離については、この1つのモジュールのみの異なる実装から得られたパフォーマンス測定値のみを比較します。しかし、システム全体は、軽量プロファイリングフレームワークに定義されたカテゴリの1つをダンプし、外部スクリプト環境を使用して、その場で役立つと思われる方法で結果を解釈できるように設定されています。パフォーマンスプロファイリングの側面を方程式から外して、私はさらに

• すべてのモデル/テクスチャ/サウンドを含むすべてのマップをロードし、異常がないかエンジンログをチェックして、すべてのアセットの有効性/一貫性を確認します
• エンジンのストレステストを行い、数時間/日の期間にわたって予期しない動作がないかログを監視する

あなたが有用なツールとして説明していることがわかりません。開発者として、単純なパフォーマンス値はほとんど役に立ちません。

必要なのは、コードのプロファイルを作成し、それを論理的なチャンクに分割して、それぞれが使用するピーク時間と平均時間を測定することです。これで、コードのどの部分が問題を引き起こしているかを知ることができ、最適化を探す場所がわかります。

トリッキーな部分は、あるビルドから別のビルドへのパフォーマンスの変更ではありません。それを把握するための自動化は必要ありません。トリッキーな部分は、異なるマシン間のパフォーマンスの違いです。異なるビデオカードを使用して、あるマシンから別のマシンにパフォーマンスを推定する方法はありません。

したがって、必要なのは、1回のクリックで実行してプロファイリング数を取得できるようにするベンチマーク機能です。これにより、複数のマシンを同時にテストできます。これにはいくつかの方法があります。たとえば、ユーザー入力をオーバーライドして、通常のゲームセッションの実行にできるだけ近づけることができます。

また、メモリリークを特定するために、より長いテストが必要になる場合もあります。