log4netまたはlog.DebugFormat(...)に精通していません。
しかし、ロギングのコストは実際には2つの領域にあります。
1つ目はロギング呼び出しであり、2つ目はログ情報の実際の永続化です。
ガードは、ロギングが実際に必要でない場合に、ロギング呼び出しを最小限に抑えるのに役立ちます。これは、メソッド呼び出しと2つのスカラーの比較にすぎないため、非常に高速になる傾向があります。
ただし、ガードを使用しない場合、コストは実際のロギング引数を作成するコストになる可能性があります。
たとえば、log4jでは、これは一般的なイディオムでした。
log.debug("Runtime error. Order #" + order.getOrderNo() + " is not posted.");
ここでのコストは、メッセージを作成する文字列式の実際の評価です。これは、ログレベルに関係なく、その式と結果の文字列が作成されるためです。代わりに次のようなものがあると想像してください。
log.debug("Something wrong with this list: " + longListOfData);
これにより、大きくて高価な文字列変数が作成される可能性があり、ログレベルがDEBUGに設定されていないと、単に無駄になります。
警備員:
if (log.isDebug()) {
log.debug(...);
}
isDebug呼び出しは、特に引数の実際の作成と比較して安価であるため、この問題を排除します。
私のコードでは、ログのラッパーを作成しました。次のようなログを作成できます。
log.debug("Runtime error. Order # {0} is not posted.", order.getOrderNo());
これは良い妥協案です。これはJavavarargsに依存しており、私のコードはロギングレベルをチェックしてから、メッセージを適切にフォーマットします。これは警備員とほぼ同じくらい速いですが、書くのはずっときれいです。
さて、log.DebugFormatも同様のことをするかもしれませんが、私にはわかりません。
もちろん、これに加えて、ログ記録の実際のコスト(画面、ファイル、ソケットなど)があります。しかし、それはあなたが受け入れる必要のあるコストです。そのための私のベストプラクティスは、実用的な場合、実際のログメッセージをキューにルーティングすることです。キューは、別のスレッドを使用して取得され、適切なチャネルに出力されます。これは、少なくとも、メインコンピューティングとのログアウトを維持するのに役立ちますが、それ自体に費用と複雑さがあります。