我编写了一些代码来测试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的值。
当我用一个try-catch块在Fibo（）中包装for循环时，如下所示：
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 ...-实际上运行得更快！但为什么？
注意：我使用Release配置对它进行了编译，并直接运行EXE文件（在Visual Studio外部）。
编辑：乔恩·斯凯特（Jon Skeet）的出色分析表明，在这种特定情况下，try-catch导致x86 CLR以更有利的方式使用CPU寄存器（而且我认为我们尚不了解原因）。我证实了乔恩（Jon）的发现，即x64 CLR没有这种区别，并且它比x86 CLR更快。我还测试int了在Fibo方法中使用类型而不是long类型，然后x86 CLR与x64 CLR一样快。
更新：看起来这个问题已由罗斯林（Roslyn）解决。同一台机器，相同的CLR版本-使用VS 2013进行编译时，问题仍然如上，但使用VS 2015进行编译时，问题就消失了。
111
@Lloyd他试图回答他的问题“它实际上运行得更快！但是为什么呢？”
—
Andreas Niedermair 2012年
因此，现在“吞咽异常”已从一种不好的做法转变为一种良好的性能优化方法：P
—
Luciano
这是在未经检查的还是经过检查的算术上下文中？
—
Random832
@ taras.roshko：虽然我不希望对Eric造成伤害，但这并不是一个真正的C＃问题-它是一个JIT编译器问题。最终的困难是弄清楚为什么x86 JIT在没有try / catch的情况下不使用与try / catch块相同的寄存器的原因。
—
乔恩·斯基特
太好了，因此，如果我们将这些尝试的渔获物嵌套起来，我们可以走得更快吗？
—
13年