(内部の最初のコードである条件が満たされないため) すぐに戻る .NET のメソッドを呼び出すオーバーヘッドは何ですか?
アプリケーションがどれほどリアルタイムであっても、そのオーバーヘッドは無視できるものであり、いずれにせよプロファイリングは事実を示すべきであり、可読性がより重要であると主張しますが、一部の同僚は私に同意せず、あなたがすべきだと言います常にそれらの呼び出しを避けてください...
他に意見は?
(内部の最初のコードである条件が満たされないため) すぐに戻る .NET のメソッドを呼び出すオーバーヘッドは何ですか?
アプリケーションがどれほどリアルタイムであっても、そのオーバーヘッドは無視できるものであり、いずれにせよプロファイリングは事実を示すべきであり、可読性がより重要であると主張しますが、一部の同僚は私に同意せず、あなたがすべきだと言います常にそれらの呼び出しを避けてください...
他に意見は?
私はあえてそれが重要であるかもしれないいくつかのエッジケースがあると言います-しかしそれらは消えていくほどまれです。私はあなたに同意します:最初に読みやすさのために書いてください。
メソッドが極端に短い場合は、JITコンパイラーがインライン化する場合がありますが、たまたますぐに終了する大きなメソッドの場合は、おそらくそうではないことに注意してください。極端な場合は、メソッドを2つに分割することをお勧めします。1つはメソッドの残りの部分が有効かどうかをテストするための短いメソッド(インライン化可能)で、もう1つは実際に作業を行うためのものです。次に、最初にテストを実行してから、2番目のメソッドを呼び出すことができます。率直に言って、私はそれがあまり好きではなく、これが本当に問題であることがわかった後にのみそれを行うことを提案します...しかし、少なくとも、それが実際に示されている最終的な事態について同僚に提案があります問題 :)
メソッド呼び出しを回避する理由として考えたいことの1つは、引数の評価に時間がかかる場合です。たとえば、ロギングについて考えてみましょう。
Log.Info("I did something: {0}", action.GenerateDescription());
時間がかかる場合GenerateDescription
は、ログが記録されない場合は実行したくないので、次のように記述できます。
if (Log.IsEnabled(LogLevel.Info))
{
Log.Info("I did something: {0}", action.GenerateDescription());
}
もう1つの方法は、デリゲートを使用して評価を延期することです。ただし、これには独自の(小さな)コストがかかる場合があります。
Log.Info("I did something: {0}", () => action.GenerateDescription());
またはメソッドgruop変換を使用します。
Log.Info("I did something: {0}", action.GenerateDescription);
それはあなたの同僚が心配している問題ではないかもしれませんが、それは考える価値があります:)
メソッドがどのように見えるかによって異なりますが、コンパイラはそのようなメソッドも「インライン化」する場合があります。したがって、おそらくオーバーヘッドはまったくありません。