私はすでにプロファイリングを行っており、現在、私のホットスポットから可能な限りのパフォーマンスを絞り出そうとしています。
[MethodImplOptions.AggressiveInlining]とProfileOptimization クラスについて知っています。他にもありますか？
[編集] [TargetedPatchingOptOut]も発見しました。気にしないでください、どうやらそれは必要ありません。
4736 次
2 に答える
32
.NET 4.5 で追加された、jit されたコードに直接影響を与えるオプションを使い果たしました。次のステップは、生成されたマシン コードを調べて、明らかな非効率性を見つけることです。デバッガーでこれを行い、最初にオプティマイザーを無効にしないようにします。[ツール] + [オプション]、[デバッグ]、[全般] で、[モジュールの読み込み時に JIT 最適化を抑制する] オプションのチェックを外します。ホット コード、デバッグ + 逆アセンブリにブレークポイントを設定して確認します。
考慮すべき点はそれほど多くありませんが、ジッター オプティマイザは一般的に優れた機能を果たします。探すべきことの 1 つは、配列境界チェックを排除しようとして失敗したことです。fixedキーワードは、そのための安全でない回避策です。まれなケースとして、メソッドのインライン化の試みが失敗し、ジッターが CPU レジスタを効果的に使用していない、x86 ジッターの問題があり、MethodImplOptions.NoInlining で修正されています。オプティマイザーは、不変コードをループから引き上げるのに非常に効率的ではありませんが、最適化の方法を探すときに C# コードをじっと見つめているときに、ほとんど常に最初に検討することです。
知りたい最も重要なことは、いつ作業が完了し、それ以上速くなることを望んでいないかということです. リンゴとオレンジを比較し、C++/CLI を使用してネイティブ コードでホット コードを記述することによってのみ、実際にそこにたどり着くことができます。このコードが有効な #pragma unmanaged でコンパイルされていることを確認して、オプティマイザが完全に機能するようにしてください。マネージ コードからネイティブ コード実行への切り替えにはコストがかかるため、ネイティブ コードの実行時間が十分に長いことを確認してください。そうでなければ、これは必ずしも簡単に実行できるとは限らず、確実に成功する保証はありません。とはいえ、完了したことを知っていると、死んだ路地に出くわす時間を大幅に節約できます.
于 2013-05-01T11:40:39.423 に答える