我写了一些代码来测试 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 更快。我还在 Fibo 方法中使用int类型而不是long类型进行了测试，然后 x86 CLR 和 x64 CLR 一样快。
更新：看起来这个问题已由 Roslyn 修复。相同的机器，相同的 CLR 版本 - 在使用 VS 2013 编译时问题仍然如上所述，但在使用 VS 2015 编译时问题就消失了。
专门了解堆栈使用优化的Roslyn工程师之一看了一下这个并告诉我，C＃编译器生成局部变量存储的方式与JIT编译器注册方式之间的交互似乎存在问题在相应的 x86 代码中进行调度。结果是在本地的加载和存储上生成次优代码。
由于某些原因我们所有人都不清楚，当 JITter 知道该块在 try-protected 区域时，可以避免有问题的代码生成路径。
这很奇怪。我们将跟进 JITter 团队，看看我们是否可以输入错误，以便他们可以解决这个问题。
此外，我们正在努力改进 Roslyn 到 C＃和 VB 编译器的算法，以确定何时可以使本地变为 “短暂” - 也就是说，只是在堆栈上推送和弹出，而不是在堆栈上分配特定位置激活的持续时间。我们相信 JITter 能够更好地完成寄存器分配，如果我们给出更好的提示，可以让当地人更早地 “死”。
感谢您引起我们的注意，并为奇怪的行为道歉。
好吧，你对事情进行计时的方式对我来说非常讨厌。对整个循环进行计时会更加明智：
var stopwatch = Stopwatch.StartNew();
for (int i = 1; i < 100000000; i++)
{
Fibo(100);
}
stopwatch.Stop();
Console.WriteLine("Elapsed time: {0}", stopwatch.Elapsed);这样你就不会受到微小时序，浮点运算和累积误差的影响。
进行了更改后，查看 “非捕获” 版本是否仍然比 “catch” 版本慢。
编辑：好的，我自己尝试过 - 我看到的结果相同。很奇怪。我想知道 try / catch 是否禁用了一些错误的内联，但使用[MethodImpl(MethodImplOptions.NoInlining)]却没有帮助...
基本上你需要在 cordbg 下查看优化的 JITted 代码，我怀疑......
编辑：一些信息：
n++;周围n++; line 仍然提高了性能，但并没有将它放在整个块上ArgumentException ），它仍然很快奇怪的...
编辑：好的，我们有拆卸......
这是使用 C＃2 编译器和. NET 2（32 位）CLR，使用 mdbg 进行反汇编（因为我的机器上没有 cordbg）。即使在调试器下，我仍然会看到相同的性能影响。快速版本使用try块来处理变量声明和 return 语句之间的所有内容，只使用catch{}处理程序。显然慢速版本是相同的，除了没有 try / catch。调用代码（即 Main）在两种情况下都是相同的，并且具有相同的程序集表示（因此它不是内联问题）。
快速版本的反汇编代码：
[0000] push ebp
[0001] mov ebp,esp
[0003] push edi
[0004] push esi
[0005] push ebx
[0006] sub esp,1Ch
[0009] xor eax,eax
[000b] mov dword ptr [ebp-20h],eax
[000e] mov dword ptr [ebp-1Ch],eax
[0011] mov dword ptr [ebp-18h],eax
[0014] mov dword ptr [ebp-14h],eax
[0017] xor eax,eax
[0019] mov dword ptr [ebp-18h],eax
*[001c] mov esi,1
[0021] xor edi,edi
[0023] mov dword ptr [ebp-28h],1
[002a] mov dword ptr [ebp-24h],0
[0031] inc ecx
[0032] mov ebx,2
[0037] cmp ecx,2
[003a] jle 00000024
[003c] mov eax,esi
[003e] mov edx,edi
[0040] mov esi,dword ptr [ebp-28h]
[0043] mov edi,dword ptr [ebp-24h]
[0046] add eax,dword ptr [ebp-28h]
[0049] adc edx,dword ptr [ebp-24h]
[004c] mov dword ptr [ebp-28h],eax
[004f] mov dword ptr [ebp-24h],edx
[0052] inc ebx
[0053] cmp ebx,ecx
[0055] jl FFFFFFE7
[0057] jmp 00000007
[0059] call 64571ACB
[005e] mov eax,dword ptr [ebp-28h]
[0061] mov edx,dword ptr [ebp-24h]
[0064] lea esp,[ebp-0Ch]
[0067] pop ebx
[0068] pop esi
[0069] pop edi
[006a] pop ebp
[006b] ret用于慢速版本的反汇编代码：
[0000] push ebp
[0001] mov ebp,esp
[0003] push esi
[0004] sub esp,18h
*[0007] mov dword ptr [ebp-14h],1
[000e] mov dword ptr [ebp-10h],0
[0015] mov dword ptr [ebp-1Ch],1
[001c] mov dword ptr [ebp-18h],0
[0023] inc ecx
[0024] mov esi,2
[0029] cmp ecx,2
[002c] jle 00000031
[002e] mov eax,dword ptr [ebp-14h]
[0031] mov edx,dword ptr [ebp-10h]
[0034] mov dword ptr [ebp-0Ch],eax
[0037] mov dword ptr [ebp-8],edx
[003a] mov eax,dword ptr [ebp-1Ch]
[003d] mov edx,dword ptr [ebp-18h]
[0040] mov dword ptr [ebp-14h],eax
[0043] mov dword ptr [ebp-10h],edx
[0046] mov eax,dword ptr [ebp-0Ch]
[0049] mov edx,dword ptr [ebp-8]
[004c] add eax,dword ptr [ebp-1Ch]
[004f] adc edx,dword ptr [ebp-18h]
[0052] mov dword ptr [ebp-1Ch],eax
[0055] mov dword ptr [ebp-18h],edx
[0058] inc esi
[0059] cmp esi,ecx
[005b] jl FFFFFFD3
[005d] mov eax,dword ptr [ebp-1Ch]
[0060] mov edx,dword ptr [ebp-18h]
[0063] lea esp,[ebp-4]
[0066] pop esi
[0067] pop ebp
[0068] ret在每种情况下， *表示调试器在简单的 “步入” 中输入的位置。
编辑：好的，我现在已经查看了代码，我想我可以看到每个版本的工作方式...... 我相信较慢的版本较慢，因为它使用较少的寄存器和更多的堆栈空间。对于可能更快的小n值 - 但是当循环占用大部分时间时，它会变慢。
try / catch 块可能会强制保存和恢复更多的寄存器，因此 JIT 也会将这些寄存器用于循环...... 这样可以提高整体性能。目前尚不清楚 JIT 是否合理地决定不在 “普通” 代码中使用尽可能多的寄存器。
编辑：刚试了我的 x64 机器。在 64 位 CLR 的速度要快得多（约 3-4 倍的速度）比该代码在 x86 CLR，并在 x64 的 try / catch 块不会使一个显着的差异。
Jon 的反汇编显示，两个版本之间的区别在于快速版本使用一对寄存器（ esi,edi ）来存储慢速版本不存在的局部变量之一。
JIT 编译器对包含 try-catch 块的代码与不代码的代码的寄存器使用做出了不同的假设。这导致它做出不同的寄存器分配选择。在这种情况下，这有利于 try-catch 块的代码。不同的代码可能导致相反的效果，所以我不认为这是一种通用的加速技术。
最后，很难说哪些代码最终会以最快的速度运行。寄存器分配和影响它的因素之类的是低级实现细节，我不知道任何特定技术如何能够可靠地生成更快的代码。
例如，请考虑以下两种方法。它们改编自现实生活中的例子：
interface IIndexed { int this[int index] { get; set; } }
struct StructArray : IIndexed {
public int[] Array;
public int this[int index] {
get { return Array[index]; }
set { Array[index] = value; }
}
}
static int Generic<T>(int length, T a, T b) where T : IIndexed {
int sum = 0;
for (int i = 0; i < length; i++)
sum += a[i] * b[i];
return sum;
}
static int Specialized(int length, StructArray a, StructArray b) {
int sum = 0;
for (int i = 0; i < length; i++)
sum += a[i] * b[i];
return sum;
}一个是另一个的通用版本。用StructArray替换泛型类型会使方法相同。因为StructArray是一个值类型，所以它获得了自己的泛型方法的编译版本。然而实际运行时间明显长于专用方法，但仅适用于 x86。对于 x64，时间几乎完全相同。在其他情况下，我也观察到了 x64 的差异。