例外がスローされない場合、try / catchブロックはパフォーマンスを低下させますか？

マイクロソフトの従業員とのコードレビュー中に、try{}ブロック内のコードの大きなセクションに遭遇しました。彼女とIT担当者は、これがコードのパフォーマンスに影響を与える可能性があることを示唆しました。実際、彼らはほとんどのコードはtry / catchブロックの外にあるべきであり、重要なセクションだけがチェックされるべきであると提案しました。マイクロソフト社の従業員は、次のホワイトペーパーを追加して、不正なtry / catchブロックに対して警告を発すると述べています。

調べてみたところ、最適化に影響する可能性があることがわかりましたが、スコープ間で変数が共有されている場合にのみ適用されるようです。

私はコードの保守性について質問したり、適切な例外を処理したりすることもしていません（問題のコードは間違いなくリファクタリングが必要です）。フロー制御の例外の使用についても言及していません。これはほとんどの場合明らかに間違っています。これらは重要な問題です（いくつかはより重要です）が、ここでは焦点を当てていません。

例外がスローされない場合、try / catchブロックはパフォーマンスにどのように影響しますか？

確認してください。

static public void Main(string[] args)
{
    Stopwatch w = new Stopwatch();
    double d = 0;

    w.Start();

    for (int i = 0; i < 10000000; i++)
    {
        try
        {
            d = Math.Sin(1);
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }
    }

    w.Stop();
    Console.WriteLine(w.Elapsed);
    w.Reset();
    w.Start();

    for (int i = 0; i < 10000000; i++)
    {
        d = Math.Sin(1);
    }

    w.Stop();
    Console.WriteLine(w.Elapsed);
}

出力：

00:00:00.4269033  // with try/catch
00:00:00.4260383  // without.

ミリ秒単位：

449
416

新しいコード：

for (int j = 0; j < 10; j++)
{
    Stopwatch w = new Stopwatch();
    double d = 0;
    w.Start();

    for (int i = 0; i < 10000000; i++)
    {
        try
        {
            d = Math.Sin(d);
        }

        catch (Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }

        finally
        {
            d = Math.Sin(d);
        }
    }

    w.Stop();
    Console.Write("   try/catch/finally: ");
    Console.WriteLine(w.ElapsedMilliseconds);
    w.Reset();
    d = 0;
    w.Start();

    for (int i = 0; i < 10000000; i++)
    {
        d = Math.Sin(d);
        d = Math.Sin(d);
    }

    w.Stop();
    Console.Write("No try/catch/finally: ");
    Console.WriteLine(w.ElapsedMilliseconds);
    Console.WriteLine();
}

新しい結果：

   try/catch/finally: 382
No try/catch/finally: 332

   try/catch/finally: 375
No try/catch/finally: 332

   try/catch/finally: 376
No try/catch/finally: 333

   try/catch/finally: 375
No try/catch/finally: 330

   try/catch/finally: 373
No try/catch/finally: 329

   try/catch/finally: 373
No try/catch/finally: 330

   try/catch/finally: 373
No try/catch/finally: 352

   try/catch/finally: 374
No try/catch/finally: 331

   try/catch/finally: 380
No try/catch/finally: 329

   try/catch/finally: 374
No try/catch/finally: 334

try / catchを持つためとのtry / catchせずに、すべての統計情報を見た後、好奇心を見て私を強制的に後ろの両方のケースのために生成されるかを確認します。これがコードです：

C＃：

private static void TestWithoutTryCatch(){
    Console.WriteLine("SIN(1) = {0} - No Try/Catch", Math.Sin(1)); 
}

MSIL：

.method private hidebysig static void  TestWithoutTryCatch() cil managed
{
  // Code size       32 (0x20)
  .maxstack  8
  IL_0000:  nop
  IL_0001:  ldstr      "SIN(1) = {0} - No Try/Catch"
  IL_0006:  ldc.r8     1.
  IL_000f:  call       float64 [mscorlib]System.Math::Sin(float64)
  IL_0014:  box        [mscorlib]System.Double
  IL_0019:  call       void [mscorlib]System.Console::WriteLine(string,
                                                                object)
  IL_001e:  nop
  IL_001f:  ret
} // end of method Program::TestWithoutTryCatch

C＃：

private static void TestWithTryCatch(){
    try{
        Console.WriteLine("SIN(1) = {0}", Math.Sin(1)); 
    }
    catch (Exception ex){
        Console.WriteLine(ex);
    }
}

MSIL：

.method private hidebysig static void  TestWithTryCatch() cil managed
{
  // Code size       49 (0x31)
  .maxstack  2
  .locals init ([0] class [mscorlib]System.Exception ex)
  IL_0000:  nop
  .try
  {
    IL_0001:  nop
    IL_0002:  ldstr      "SIN(1) = {0}"
    IL_0007:  ldc.r8     1.
    IL_0010:  call       float64 [mscorlib]System.Math::Sin(float64)
    IL_0015:  box        [mscorlib]System.Double
    IL_001a:  call       void [mscorlib]System.Console::WriteLine(string,
                                                                  object)
    IL_001f:  nop
    IL_0020:  nop
    IL_0021:  leave.s    IL_002f //JUMP IF NO EXCEPTION
  }  // end .try
  catch [mscorlib]System.Exception 
  {
    IL_0023:  stloc.0
    IL_0024:  nop
    IL_0025:  ldloc.0
    IL_0026:  call       void [mscorlib]System.Console::WriteLine(object)
    IL_002b:  nop
    IL_002c:  nop
    IL_002d:  leave.s    IL_002f
  }  // end handler
  IL_002f:  nop
  IL_0030:  ret
} // end of method Program::TestWithTryCatch

私はILの専門家ではありませんが、ローカル例外オブジェクトが4行目に作成され、.locals init ([0] class [mscorlib]System.Exception ex)その後17行目まではtry / catchを使用しないメソッドの場合とほぼ同じIL_0021: leave.s IL_002fです。例外が発生すると、コントロールは行IL_0025: ldloc.0にジャンプしIL_002d: leave.s IL_002fます。それ以外の場合は、ラベルにジャンプし、関数が戻ります。

例外が発生しない場合は、例外オブジェクトとジャンプ命令のみを保持するのがローカル変数の作成のオーバーヘッドであると、私は安全に想定できます。

いいえ。try/ finallyブロックが取るに足らない最適化によって実際にプログラムに測定可能な影響がある場合は、最初から.NETを使用しないでください。

.NET例外モデルのかなり包括的な説明。

リコマリアーニのパフォーマンスのヒント：例外コスト：スローするタイミングとしないタイミング

最初の種類のコストは、コードで例外処理を行う静的コストです。管理された例外は実際にはここで比較的うまく機能します。つまり、静的コストはC ++で言うよりもはるかに低くなる可能性があります。どうしてこれなの？静的コストは、実際には2種類の場所で発生します。1つ目は、try / finally / catch / throwの実際のサイトで、これらの構成要素のコードがある場所です。次に、アンマネージコードでは、例外がスローされた場合に破棄する必要があるすべてのオブジェクトを追跡することに関連するステルスコストがあります。存在しなければならないかなりの量のクリーンアップロジックがあり、卑劣な部分は、

ドミトリ・ザスラフスキー：

Chris Brummeのメモによると：キャッチが存在する場合、JITによって一部の最適化が実行されないという事実に関連するコストもあります。

この例では、構造がBen Mと異なります。これは、内部forループ内のオーバーヘッドが拡張されるため、2つのケースを適切に比較できなくなります。

以下は、チェックするコード全体（変数の宣言を含む）がTry / Catchブロック内にある比較の方が正確です。

        for (int j = 0; j < 10; j++)
        {
            Stopwatch w = new Stopwatch();
            w.Start();
            try { 
                double d1 = 0; 
                for (int i = 0; i < 10000000; i++) { 
                    d1 = Math.Sin(d1);
                    d1 = Math.Sin(d1); 
                } 
            }
            catch (Exception ex) {
                Console.WriteLine(ex.ToString()); 
            }
            finally { 
                //d1 = Math.Sin(d1); 
            }
            w.Stop(); 
            Console.Write("   try/catch/finally: "); 
            Console.WriteLine(w.ElapsedMilliseconds); 
            w.Reset(); 
            w.Start(); 
            double d2 = 0; 
            for (int i = 0; i < 10000000; i++) { 
                d2 = Math.Sin(d2);
                d2 = Math.Sin(d2); 
            } 
            w.Stop(); 
            Console.Write("No try/catch/finally: "); 
            Console.WriteLine(w.ElapsedMilliseconds); 
            Console.WriteLine();
        }

Ben Mの元のテストコードを実行したところ、Debug構成とReleas構成の両方に違いがあることに気付きました。

このバージョンでは、デバッグバージョンの違い（実際には他のバージョンよりも多い）に気づきましたが、リリースバージョンの違いはありませんでした。

結論：
これらのテストに基づくと、Try / Catchはパフォーマンスにわずかな影響を与えると言えます。

編集：
ループ値を10000000から1000000000に増やして、リリースで再度実行してリリースにいくつかの違いを付けようとしましたが、結果は次のとおりでした：

   try/catch/finally: 509
No try/catch/finally: 486

   try/catch/finally: 479
No try/catch/finally: 511

   try/catch/finally: 475
No try/catch/finally: 477

   try/catch/finally: 477
No try/catch/finally: 475

   try/catch/finally: 475
No try/catch/finally: 476

   try/catch/finally: 477
No try/catch/finally: 474

   try/catch/finally: 475
No try/catch/finally: 475

   try/catch/finally: 476
No try/catch/finally: 476

   try/catch/finally: 475
No try/catch/finally: 476

   try/catch/finally: 475
No try/catch/finally: 474

結果は重要ではないことがわかります。場合によっては、実際にはTry / Catchを使用したバージョンの方が高速です。

try..catchタイトループでaの実際の影響をテストしましたが、それ自体は小さすぎて、通常の状況ではパフォーマンスの問題にはなりません。

ループがほとんど機能しない場合（私のテストではを実行しましたx++）、例外処理の影響を測定できます。例外処理を含むループの実行には、約10倍の時間がかかりました。

ループが実際の作業を行う場合（私のテストでは、Int32.Parseメソッドを呼び出しました）、例外処理の影響が小さすぎて測定できません。ループの順序を入れ替えることで、はるかに大きな違いが生まれました...

catchブロックを試してもパフォーマンスへの影響はごくわずかですが、例外のスローはかなり大きくなる可能性があります。これはおそらく同僚が混乱した場所です。

try / catchはパフォーマンスに影響します。

しかし、それは大きな影響ではありません。try / catchの複雑さは、ループに配置される場合を除いて、単純な割り当てと同じように、通常O（1）です。したがって、それらを賢く使用する必要があります。

以下は、try / catchのパフォーマンスに関するリファレンスです（ただし、その複雑さについては説明していませんが、暗示されています）。「例外のスローを減らす」セクションをご覧ください

理論的には、実際に例外が発生しない限り、try / catchブロックはコードの動作に影響を与えません。ただし、try / catchブロックの存在が大きな影響を与える可能性のあるまれな状況と、その影響が顕著になる可能性のある、あまり一般的ではないがほとんど不明瞭な状況があります。この理由は、次のようなコードが指定されているためです。

Action q;
double thing1()
  { double total; for (int i=0; i<1000000; i++) total+=1.0/i; return total;}
double thing2()
  { q=null; return 1.0;}
...
x=thing1();     // statement1
x=thing2(x);    // statement2
doSomething(x); // statement3

コンパイラーは、statement2がstatement3の前に実行されることが保証されているという事実に基づいて、statement1を最適化できる場合があります。コンパイラがthing1に副作用がなく、thing2が実際にxを使用していないことを認識できる場合は、thing1を完全に省略してもかまいません。[この場合のように] thing1が高価な場合、それは大きな最適化になる可能性がありますが、thing1が高価な場合も、コンパイラーが最適化する可能性が最も低いケースです。コードが変更されたとしましょう：

x=thing1();      // statement1
try
{ x=thing2(x); } // statement2
catch { q(); }
doSomething(x);  // statement3

これで、statement2を実行せずにstatement3を実行できる一連のイベントが存在します。のコードでthing2例外がスローされない場合でも、別のスレッドがを使用しInterlocked.CompareExchangeてqクリアされたことを通知しThread.ResetAbort、それをに設定してから、Thread.Abort()beforeステートメント2を実行してその値をに書き込む可能性がありますx。そして、catch実行でしょうThread.ResetAbort()[デリゲート経由でq実行がstatement3を続行することができ、]。もちろん、そのような一連のイベントは例外的にありそうもありませんが、そのようなありそうもないイベントが発生した場合でも、仕様に従って機能するコードを生成するにはコンパイラーが必要です。

一般に、コンパイラーは複雑なコードよりも単純なコードを除外する機会に気づく可能性が高いため、例外がスローされない場合、try / catchがパフォーマンスに大きな影響を与えることはまれです。それでも、try / catchブロックの存在によって最適化が妨げられる場合があります。ただし、try / catchの場合はコードの実行が高速化されていました。

「処理よりも防止の方が優れています」が、パフォーマンスと効率の観点から、事前変動よりも試行キャッチを選択することができました。以下のコードを考えてみましょう：

Stopwatch stopwatch = new Stopwatch();
stopwatch.Start();
for (int i = 1; i < int.MaxValue; i++)
{
    if (i != 0)
    {
        int k = 10 / i;
    }
}
stopwatch.Stop();
Console.WriteLine($"With Checking: {stopwatch.ElapsedMilliseconds}");
stopwatch.Reset();
stopwatch.Start();
for (int i = 1; i < int.MaxValue; i++)
{
    try
    {
        int k = 10 / i;
    }
    catch (Exception)
    {

    }
}
stopwatch.Stop();
Console.WriteLine($"With Exception: {stopwatch.ElapsedMilliseconds}");

結果は次のとおりです。

With Checking: 20367
With Exception: 13998

例外が発生しない場合に、try / catchブロックがどのように機能するか、および一部の実装でオーバーヘッドが高く、一部でゼロのオーバーヘッドがある実装の説明については、try / catch実装に関する説明を参照してください。特に、Windows 32ビットの実装には高いオーバーヘッドがあり、64ビットの実装にはないオーバーヘッドがあると思います。