try-catchの影響をテストするためにいくつかのコードを書きましたが、驚くべき結果がいくつかありました。
static void Main(string[] args)
{
Thread.CurrentThread.Priority = ThreadPriority.Highest;
Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.RealTime;
long start = 0, stop = 0, elapsed = 0;
double avg = 0.0;
long temp = Fibo(1);
for (int i = 1; i < 100000000; i++)
{
start = Stopwatch.GetTimestamp();
temp = Fibo(100);
stop = Stopwatch.GetTimestamp();
elapsed = stop - start;
avg = avg + ((double)elapsed - avg) / i;
}
Console.WriteLine("Elapsed: " + avg);
Console.ReadKey();
}
static long Fibo(int n)
{
long n1 = 0, n2 = 1, fibo = 0;
n++;
for (int i = 1; i < n; i++)
{
n1 = n2;
n2 = fibo;
fibo = n1 + n2;
}
return fibo;
}
私のコンピュータでは、これは常に0.96前後の値を出力します。
forループを次のようなtry-catchブロックでFibo（）内にラップすると、
static long Fibo(int n)
{
long n1 = 0, n2 = 1, fibo = 0;
n++;
try
{
for (int i = 1; i < n; i++)
{
n1 = n2;
n2 = fibo;
fibo = n1 + n2;
}
}
catch {}
return fibo;
}
今では一貫して0.69を出力します...-実際にはより速く実行されます！しかし、なぜ？
注：リリース構成を使用してこれをコンパイルし、直接EXEファイル（Visual Studioの外部）を実行しました。
編集：ジョンスキートの優れた分析は、try-catchが何らかの理由でx86 CLRにこの特定のケースでより好ましい方法でCPUレジスターを使用させていることを示しています（そして、私たちはまだ理由を理解していません）。x64 CLRにはこの違いがなく、x86 CLRよりも高速であるというJonの発見を確認しました。またint、long型の代わりにFiboメソッド内の型を使用してテストしたところ、x86 CLRはx64 CLRと同等の速さでした。
更新：この問題はRoslynによって修正されたようです。同じマシン、同じCLRバージョン-VS 2013でコンパイルすると問題は上記のように残りますが、VS 2015でコンパイルすると問題はなくなります。
111
@ロイドは彼が彼の質問に対して答えを得ようと試みます「それは実際により速く走ります！
—
Andreas Niedermair 2012年
だから、今の良好なパフォーマンスの最適化には悪い習慣であることから渡された「例外呑む」：Pを
—
ルチアーノ
これは、未チェックまたはチェック済みの算術コンテキストですか？
—
Random832 2012年
@ taras.roshko：私はエリックに邪魔をしたくありませんが、これは実際にはC＃の質問ではありません-JITコンパイラの質問です。究極の難しさは、それがないのx86 JITはのtry / catchすることなく、多くのレジスタとして使用していない理由を働いていると try / catchブロック。
—
Jon Skeet
甘いので、これらのトライキャッチをネストすると、さらに速く進むことができますか？
—
チャックピンケルト2013