「通常の」ビジネスプログラミングの最適化手順は、本当に必要になるまでしばしば残されます。つまり、本当に必要になるまで最適化しないでください。
ドナルド・クヌースが言ったことを思い出してください。「私たちは小さな効率を忘れて、約97％の時間を言うべきです。早すぎる最適化はすべての悪の根源です」
努力を無駄にしないように最適化するときはいつですか。メソッドレベルにする必要がありますか？クラスレベル？モジュールレベル？
また、最適化の測定値は何ですか？ダニ？フレームレート？合計時間？
「通常の」ビジネスプログラミングの最適化手順は、本当に必要になるまでしばしば残されます。つまり、本当に必要になるまで最適化しないでください。
ドナルド・クヌースが言ったことを思い出してください。「私たちは小さな効率を忘れて、約97％の時間を言うべきです。早すぎる最適化はすべての悪の根源です」
努力を無駄にしないように最適化するときはいつですか。メソッドレベルにする必要がありますか？クラスレベル？モジュールレベル？
また、最適化の測定値は何ですか？ダニ？フレームレート？合計時間？
回答:
私が働いたところでは、常に複数レベルのプロファイリングを使用しています。問題が発生した場合は、何が起こっているかがわかるまで、リストをさらに下に移動するだけです。
（幸福、無関心、イライラ、怒りの4枚の写真を撮り、フレームレートに基づいて内部ビルドの隅に適切な写真を表示したグラフィックプログラマーの過去1年間のGDCからの楽しいストーリーがあります。コンテンツ作成者は、すべてのオブジェクトと環境に対して複雑なシェーダーを有効にしないことをすぐに学びました。プログラマーを怒らせます。フィードバックの力を見守ってください。）
「プロファイルバー」を連続的にグラフ化するなどの楽しいこともできるため、スパイクパターン（「7フレームごとにフレームが失われている」）などを確認できます。
（そして多くの場合、やりがいの-私は通常何かを学ぶ）、それは魅力的ですが、私の経験では、命令または命令キャッシュやデータキャッシュのパフォーマンスの最適化番号に単一の機能/モジュールを書き換えるために、私たちは実際にんけれども、直接あなたの質問に答えるために必要とやってこれは、特に不快なパフォーマンスの問題が発生したときに、定期的に対処するパフォーマンスの問題の大部分が設計に起因することがあります。例えば：
大学レベルのコンピューターサイエンスコースで不快になるまで、あなたはそれを聞きますが、それは本当にデータ構造とアルゴリズムに関するものです。アルゴリズムとデータフローの設計に少し時間をかけることで、一般的な投資に見合うだけの価値を得ることができます。（Sony Developer Servicesフェローからのオブジェクト指向プログラミングの優れた落とし穴のスライドを読んでください。ここでいくつかの洞察を得ることができます。）これは最適化のように「感じ」ません。現在のコードの実行を高速化するのではなく、ホワイトボードまたはUMLツールを使用したり、多くのプロトタイプを作成したりするのに費やした時間です。しかし、それは一般的にはるかに価値があります。
また、もう1つの有用なヒューリスティック：エンジンの「コア」に近い場合、最適化（たとえば、これらの行列の乗算をベクトル化する）に余分な労力と実験の価値があります。コアから遠いほど、プロファイリングツールのいずれかから別の指示がない限り、心配する必要は少なくなります。
ただし、「早すぎる悲観化」も忘れないでください。コードのすべての行をハードコアにする必要はありませんが、実際にゲームに取り組んでいることに気付く理由はあります。これはリアルタイムのパフォーマンスに影響を及ぼします。
誰もがホットスポットを測定して最適化するように指示しますが、その手法では、隠れた場所で失われたパフォーマンスは表示されません。たとえば、コード内のすべての「+」操作に必要な時間が2倍かかる場合、ホットスポットとして表示されないため、最適化または実現することはありませんが、それはあなたに多くのパフォーマンスを犠牲にするかもしれません。検出されずにそれらのサイクルのどれだけが滴り落ちるかに驚くでしょう。ですから、あなたが何をするのかに注意してください。
それとは別に、私は定期的にプロファイルを作成して、何があるか、フレームごとにどれだけの時間が残っているかを把握する傾向があります。私にとって、フレームレートの目標はどこにあるのかを直接教えてくれるので、フレームあたりの時間が最も論理的です。また、ピークがどこにあり、何が原因であるかを調べてみてください-スパイクのある高フレームレートよりも安定したフレームレートを好みます。
ゲームをリリースする準備ができたら（最終版またはベータ版）、または著しく遅い場合は、おそらくアプリをプロファイリングするのに最適なタイミングです。もちろん、いつでもプロファイラーを実行できます。しかし、はい、時期尚早な最適化はすべての悪の根源です。根拠のない最適化も。「最適化」を試みる前に、コードが遅いことを示すために実際のデータが必要です。プロファイラーがそれを行います。
プロファイラーについて知らない場合は、それを学んでください！ここだ優れたブログ記事プロファイラの有用性を実証するには。
ゲームコードの最適化のほとんどは、各フレームに必要なCPUサイクルを削減することです。これを行う1つの方法は、作成するすべてのルーチンを最適化し、可能な限り高速にすることです。ただし、CPUサイクルの90％がコードの10％に費やされるという一般的な言い方があります。これは、すべての最適化作業をこれらのボトルネックルーチンに向けると、すべてを均一に最適化する効果が10倍になることを意味します。では、これらのルーチンをどのように識別しますか？プロファイリングにより簡単になります。
さもなければ、小さなゲームが非効率的なアルゴリズムを持っているにもかかわらず200 FPSで実行されている場合、本当に最適化する理由がありますか？ターゲットマシンの仕様を十分に把握し、そのマシンでゲームが適切に動作することを確認する必要がありますが、それを超えると、おそらく間違いなくゲームのコーディングや洗練に費やすことができる無駄な時間になります。
プロファイリングを組み込むと便利です。積極的に最適化を行っていない場合でも、特定の時点でパフォーマンスを制限している要素を把握しておくとよいでしょう。多くのゲームには、ゲームループのさまざまな部分が各フレームを使用している時間を示す単純なグラフィカルチャート（通常は色付きのバー）を表示する、オーバーレイ可能なHUDがあります。
パフォーマンス分析と最適化を後期に遅すぎるようにするのは悪い考えです。すでにゲームをビルドしていて、CPU予算が200％を超えていて、最適化でそれを見つけられない場合は、失敗に終わります。
書くときは、グラフィックス、物理学などの予算を知る必要があります。パフォーマンスがどうなるかわからない場合、それはできません。また、パフォーマンスが何であるか、どの程度のスラックがあるかを知ることなく、それを推測することはできません。
そのため、初日からいくつかのパフォーマンス統計を組み込みます。
いつ物事に取り組むべきかについて-繰り返しますが、エンジンを半分リファクタリングしなければならないように、手遅れにしないでください。一方、明日アルゴリズムを完全に変更する可能性があると考えたり、実際のゲームデータを入れていない場合は、サイクルごとに絞り出すために最適化に縛られすぎないでください。
ぶら下がっている果物を取り除いて、定期的に大きなものに取り組むと、元気になります。
Knuthの引用をその文脈で見て、彼が説明を続けると、プロファイラーのようなツールを使用して最適化する必要があると説明します。
非常に基本的なアーキテクチャが構築された後、アプリケーションのプロファイルとメモリのプロファイルを常に行う必要があります。
プロファイリングは、速度の向上に役立つだけでなく、バグの発見にも役立ちます。プログラムが突然劇的に速度を変える場合、これは通常バグのためです。プロファイリングを行わないと、気付かない場合があります。
最適化の秘Theは、設計によってそれを行うことです。最後まで待たないでください。プログラムの設計が、本当に厄介な内部ループのトリックを使わずに、必要なパフォーマンスを提供することを確認してください。
私のプロジェクトでは、通常、非常に必要な最適化をベースエンジンに適用します。たとえば、私は常にSSE2と3DNow！を使用して、しっかりしたSIMD実装を実装したいと思っています。これにより、浮動小数点演算が目的の場所に合図されます。もう1つの優れた方法は、コードを作成するときに戻るのではなく、最適化を習慣にすることです。ほとんどの場合、これらの小さなプラクティスは、とにかくコーディングしていたのと同じくらい時間がかかります。機能をコーディングする前に、最も効率的な方法を調査してください。
結論としては、私の意見では、コードが既にひどい状態になった後、コードをより効率的にするためのハードルです。
コードの実行速度が遅い場合は、プロファイラーを実行して、正確に実行速度が遅くなる原因を確認してください。または、パフォーマンスの問題に気づき始める前にプロアクティブでプロファイラーを実行しておくこともできます。
ゲームが苦しみ始めるポイントまでフレームレートが低下したときに最適化する必要があります。最も可能性の高い犯人は、CPUが過剰に消費されていることです（100％）。
コードを最適化する必要があります...必要な頻度で。
過去に私がやったことは、プロファイリングをオンにしてゲームを継続的に実行することです（少なくとも画面上のフレームレートカウンターは常に）。ゲームが遅くなっている場合（最小スペックマシンのターゲットフレームレートなど）、プロファイラーをオンにして、ホットスポットが表示されるかどうかを確認します。
時にはコードではありません。私が過去に遭遇した問題の多くは、GPU指向のものでした（確かに、これはiPhoneにありました）。塗りつぶしの問題、描画呼び出しが多すぎる、十分なジオメトリをバッチ処理しない、非効率的なシェーダー...
困難な問題（つまり、経路探索、物理）の非効率的なアルゴリズム以外に、コード自体が原因である問題に遭遇することはほとんどありません。そして、これらの難しい問題は、アルゴリズムを正しくするために多くの労力を費やし、小さなことを心配しないことです。