try/catch对性能有影响。

但影响并不大。try/catch复杂度通常是O(1)，就像一个简单的赋值一样，除了它们被放置在一个循环中。所以你必须明智地使用它们。

这里有一个关于try/catch性能的参考(虽然没有解释它的复杂性，但它是隐含的)。请参阅抛出更少异常一节

我试了一个深接球。

        static void TryCatch(int level, int max)
        {
            try
            {
                if (level < max) TryCatch(level + 1, max);
            }
            catch
            { }
        }
        static void NoTryCatch(int level, int max)
        {
            if (level < max) NoTryCatch(level + 1, max);
        }
        static void Main(string[] args)
        {
            var s = new Stopwatch();
            const int max = 10000;
            s.Start();
            TryCatch(0, max);
            s.Stop();
            Console.WriteLine("try-catch " + s.Elapsed);
            s.Restart();
            NoTryCatch(0, max);
            s.Stop();
            Console.WriteLine("no try-catch " + s.Elapsed);
        }

结果:

try-catch 00:00:00.0008528
no try-catch 00:00:00.0002422

是的，尝试/捕捉会“损害”性能(一切都是相对的)。就浪费的CPU周期而言，这并不多，但还有其他重要的方面需要考虑:

代码大小 方法内联

基准

首先，让我们使用一些复杂的工具(例如BenchmarkDotNet)检查速度。编译为Release (AnyCPU)，在x64机器上运行。我想说没有区别，即使测试确实会告诉我们NoTryCatch()是一个很小很小的一点快:

|            Method |   N |     Mean |     Error |    StdDev |
|------------------ |---- |---------:|----------:|----------:|
|        NoTryCatch | 0.5 | 3.770 ns | 0.0492 ns | 0.0411 ns |
|      WithTryCatch | 0.5 | 4.060 ns | 0.0410 ns | 0.0384 ns |
| WithTryCatchThrow | 0.5 | 3.924 ns | 0.0994 ns | 0.0881 ns |

分析

一些额外的注释。

|            Method | Code size | Inlineable |
|------------------ |---------- |-----------:|
|        NoTryCatch |        12 |        yes |
|      WithTryCatch |        18 |          ? |
| WithTryCatchThrow |        18 |         no |

代码大小NoTryCatch()在代码中产生12个字节，而try/catch则增加6个字节。此外，每当编写try/catch语句时，您很可能会有一个或多个throw new Exception(“Message”，ex)语句，进一步“膨胀”代码。

这里最重要的是代码内联。在. net中，仅仅throw关键字的存在就意味着该方法永远不会被编译器内联(意味着代码更慢，但占用空间更少)。我最近彻底测试了这个事实，所以它在。net Core中似乎仍然有效。不确定try/catch是否遵循相同的规则。待办事项:验证!

完整的测试代码

using System;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

namespace TryCatchPerformance
{
    public class TryCatch
    {
        [Params(0.5)]
        public double N { get; set; }

        [Benchmark]
        public void NoTryCatch() => Math.Sin(N);

        [Benchmark]
        public void WithTryCatch()
        {
            try
            {
                Math.Sin(N);
            }
            catch
            {
            }
        }

        [Benchmark]
        public void WithTryCatchThrow()
        {
            try
            {
                Math.Sin(N);
            }
            catch (Exception ex)
            {
                throw;
            }
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var summary = BenchmarkRunner.Run<TryCatch>();
        }
    }
}

虽然“预防胜于处理”，但从性能和效率的角度来看，我们可以选择试接而不是预变。考虑下面的代码:

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

. net异常模型的非常全面的解释。

Rico Mariani的性能花絮:异常成本:何时抛出，何时不抛出

The first kind of cost is the static cost of having exception handling in your code at all. Managed exceptions actually do comparatively well here, by which I mean the static cost can be much lower than say in C++. Why is this? Well, static cost is really incurred in two kinds of places: First, the actual sites of try/finally/catch/throw where there's code for those constructs. Second, in unmanged code, there's the stealth cost associated with keeping track of all the objects that must be destructed in the event that an exception is thrown. There's a considerable amount of cleanup logic that must be present and the sneaky part is that even code that doesn't itself throw or catch or otherwise have any overt use of exceptions still bears the burden of knowing how to clean up after itself.

德米特里·扎斯拉夫斯基：

根据Chris Brumme的注释:有 还有一个与事实有关的成本 有些优化没有进行 由JIT在现场执行 抓

不。如果try/finally块排除的琐碎优化实际上对您的程序有可衡量的影响，那么您可能一开始就不应该使用. net。