コードサイズを小さくするためにこの情報を知りたいので、コンパイラーまたはJITによって実行されることを最適化するために時間を無駄にしないでください。
例えば：
コンパイラがプロパティのget関数の呼び出しをインライン化すると仮定すると、関数呼び出しを回避するために戻り値をローカル変数に保存する必要はありません。
何が起こっているのかを説明する良いリファレンスをお勧めしたいですか？
3516 次
4 に答える
18
これらの記事をご覧になることをお勧めします。
JIT最適化-（Sasha Goldshtein-CodeProject）
Jit最適化：インライン化I（David Notario）
Jit最適化：インライン化II（David Notario）
正直なところ、このレベルのマイクロディテールについてあまり心配する必要はありません。コンパイラ/JIT'erにこれについて心配させてください。ほとんどの場合、あなたよりも優れています。時期尚早の最適化にとらわれないでください。コードを機能させることに集中し、（a）十分な速度で実行されない場合、（b）「サイズ」の問題がある場合は、後で最適化について心配します。
于 2009-03-16T14:51:55.357 に答える
17
パフォーマンスが心配な場合は、プロファイラーを実行してください。次にコードを変更します。100 万年経っても、時間がどこに向かっているのかを 100% 正しく推測することはできないでしょう。0.02% のタイミングを変更して、負担の 62% を占めるメソッドを離れる可能性があります。悪化させている可能性もあります。プロファイラーと証拠がなければ、あなたは盲目です。
JIT がプロパティ ゲッターをインライン化すると想定することはできません。そうするかもしれないし、そうしないかもしれない多くの理由があります。メソッド本体のサイズ、仮想、値と参照型、アーキテクチャ、付属のデバッガなど。
「ホイスト」にはまだ場所があり、コードがタイトなループで繰り返し呼び出される場合でも、節約を達成できます。例えば：
var count = list.Count;
for(int i = 0 ; i < count ; i++) {...}
for（上記のvsのforeach議論は忘れてください-これは直交する議論です）。上記では、「ホイスト」がパフォーマンスに役立ちます。しかし、本当に紛らわしいだけです-配列では逆であり、巻き上げない方が効率的です:
for(int i = 0 ; i < arr.Length ; i++) {...}
JIT はこれを認識し、境界チェックを削除します (配列は固定サイズであるため)。
于 2009-03-16T14:38:37.433 に答える
1
これは、見るべきではない一種のマイクロ最適化のように見えます。私が間違っていなければ、どの種類の最適化が適用されるかは、CLR のアーキテクチャとバージョンに依存します。
メソッドが大量に呼び出され、どうしてもインライン化したい場合は、スパゲッティ コードを犠牲にして自分でインライン化できます。
メソッドをインライン化しても速度は大幅に節約されませんが、アルゴリズムを改善すると実行時間が数時間から数秒に短縮されるため、アルゴリズムを分析することをお勧めします。
于 2009-03-16T14:39:41.503 に答える
-1
通常、JIT によって実行される最も強力な最適化はインライン化です。JIT は何百もの関数を深くインライン化することさえできます (この数字は JikesRVM について聞いたことがあります)。常にインライン化できるとは限らないものもインライン化し、必要に応じて後で元に戻します (動的最適化解除と呼ばれます)。
あなたの特定の質問については、問題の関数呼び出しがhotである場合、おそらく言うでしょう。
于 2009-07-27T17:25:07.913 に答える