Console.OutputEncodingのチェックに時間がかかるのはなぜですか？

Question

私はアプリケーションでいくつかのパフォーマンスプロファイリングを実行しています。コンソール出力のエンコーディングをチェックするのは、アプリケーションが完全なパフォーマンスの繰り返しを実行するのに約2倍の時間がかかります。

は私が経由してチェックしています：

Console.OutputEncoding.EncodingName != Encoding.UTF8.EncodingName 

このチェックはこれなしで実行するために〜80ティック（8000 NS）、（コンソールテーブルを生成する）私の全体のアプリケーションのみをとる〜50ティック（5000 NS）を取り、数百の条件を通過します。

なぜ出力エンコードのチェックに時間がかかるのですか？これをスピードアップできますか？ OutputEncodingのゲッターのための

Answer 1

これは、EncodingNameを比較しているためです。その結果、高価なルックアップ（およびその後の文字列比較）が発生する可能性があります。エンコードを直接比較するだけの理由はありませんか？

!Console.OutputEncoding.Equals(Encoding.UTF8) 

これははるかに速いようにテストします。

Answer 2

リファレンスソース：https://referencesource.microsoft.com/#mscorlib/system/console.cs,594

public static Encoding OutputEncoding { 
    [System.Security.SecuritySafeCritical] // auto-generated 
    get { 

     Contract.Ensures(Contract.Result<Encoding>() != null); 

     if (null != _outputEncoding) 
      return _outputEncoding; 

     lock(InternalSyncObject) { 

      if (null != _outputEncoding) 
       return _outputEncoding; 

      uint cp = Win32Native.GetConsoleOutputCP(); 
      _outputEncoding = Encoding.GetEncoding((int) cp); 
      return _outputEncoding; 
     } 
    } 
    ... 

私が最初に気づくのは、それがロックを取っているということなので、オーバーヘッドのビットは、すでにそこにあります。それは遅れてもインスタンス化されているようです。最初にOutputEncodingを取得したら、PInvokeの後にEncoding.GetEncoding（これはわかりますが、簡単な作業ではありません）が必要です。しかし、その後のすべての呼び出しはロックを回避し、既にインスタンス化された値を返します。だから、何度もそれを取得しているならば、コストはほとんど何も償却されません。

1回だけ取得している場合... 本当には、わずか8マイクロ秒かかるものを最適化する必要がありますか？