用ChatGPT解决这个技术问题 Extra ChatGPT

当不抛出异常时，try/catch 块会损害性能吗？

在与 Microsoft 员工进行代码审查期间，我们在 try{} 块中发现了一大段代码。她和一位 IT 代表建议这可能会影响代码的性能。事实上，他们建议大部分代码应该在 try/catch 块之外，并且只检查重要的部分。微软员工补充说，即将发布的白皮书警告不要使用不正确的 try/catch 块。

我环顾四周发现它can affect optimizations，但它似乎只适用于在作用域之间共享变量时。

我不是在问代码的可维护性，甚至不是在处理正确的异常（毫无疑问，有问题的代码需要重构）。我也不是指使用异常进行流控制，这在大多数情况下显然是错误的。这些都是重要的问题（有些更重要），但不是这里的重点。

当不抛出异常时，try/catch 块如何影响性能？

“为了表现而牺牲正确性的人也不值得。”
也就是说，不必总是为了性能而牺牲正确性。
单纯的好奇心怎么样？
@Joel：也许科比只是出于好奇想知道答案。知道性能是更好还是更差并不一定意味着他会对他的代码做任何疯狂的事情。为求知识而求知不是好事吗？
这是一个很好的算法，用于知道是否进行此更改。首先，设定有意义的基于客户的绩效目标。其次，先写代码既正确又清晰。第三，根据您的目标对其进行测试。第四，如果你达到了你的目标，早点下班去海边。第五，如果您没有达到您的目标，请使用分析器来查找太慢的代码。第六，如果代码由于不必要的异常处理程序而变得太慢，那么只有删除异常处理程序。如果没有，请修复实际上太慢的代码。然后回到第三步。

A
Anatoliy Nikolaev

核实。 

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
您是否也可以以相反的顺序尝试它们以确保 JIT 编译对前者没有影响？
像这样的程序似乎不太适合测试异常处理的影响，正常的 try{} catch{} 块中发生的太多事情将被优化掉。我可能会出去吃午饭……
这是一个调试版本。 JIT 不会优化这些。
这根本不是真的，想想吧。你在一个循环中使用了多少次 try catch？大多数时候你会在 try.c 中使用循环
真的吗？ “当不抛出异常时，try/catch 块如何影响性能？”
T
TheVillageIdiot

在查看了使用 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 专家，但我们可以看到，在第 17 行 IL_0021: leave.s IL_002f 之前，在第四行 .locals init ([0] class [mscorlib]System.Exception ex) 上创建了一个本地异常对象，这与没有 try/catch 的方法完全相同。如果发生异常，则控件跳转到第 IL_0025: ldloc.0 行，否则我们跳转到标签 IL_002d: leave.s IL_002f 并且函数返回。

我可以放心地假设，如果没有发生异常，那么创建局部变量以仅保存异常对象和跳转指令是开销。

好吧，IL 包含一个与 C# 中相同符号的 try/catch 块，因此这并不能真正显示 try/catch 在幕后意味着多少开销！只是IL没有添加更多，并不意味着它没有在编译的汇编代码中添加一些东西。 IL 只是所有 .NET 语言的通用表示。它不是机器代码！
J
John Kugelman

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

这是一个很好的观点 - 与我们列表中的其他项目相比，这个应该是微不足道的。我们应该相信基本的语言特性能够正确运行，并优化我们可以控制的内容（sql、索引、算法）。
想想紧密的循环配合。示例循环，您从游戏服务器中的套接字数据流中读取和反序列化对象，并尝试尽可能多地挤压。因此，您使用 MessagePack 进行对象序列化而不是 binaryformatter，并使用 ArrayPool 而不仅仅是创建字节数组等......在这些场景中，多个（可能是嵌套的）try catch 块在紧密循环中的影响是什么。编译器将跳过一些优化，异常变量也会进入 Gen0 GC。我要说的是，在“某些”情况下，一切都会产生影响。
R
Robert Cartaino

Quite comprehensive explanation of the .NET exception model.

Rico Mariani 的表演花絮：Exception Cost: When to throw and when not to

第一种成本是在代码中进行异常处理的静态成本。托管异常在这里实际上做得比较好，我的意思是静态成本可能比 C++ 中的成本低得多。为什么是这样？好吧，静态成本确实在两种地方产生：第一，try/finally/catch/throw 的实际站点，其中有这些构造的代码。其次，在无人管理的代码中，跟踪所有在抛出异常时必须销毁的对象会产生隐秘成本。有相当多的清理逻辑必须存在，而鬼鬼祟祟的部分是，即使代码本身不抛出或捕捉或以其他方式公开使用异常，仍然承担着知道如何清理自身的负担。

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

根据 Chris Brumme 的说明：在存在 catch 的情况下，JIT 未执行某些优化这一事实也存在成本

关于 C++ 的事情是标准库的很大一部分会抛出异常。他们没有什么可选的。你必须使用某种异常策略来设计你的对象，一旦你这样做了，就没有更多的隐形成本了。
Rico Mariani 的说法对于原生 C++ 来说是完全错误的。 “静态成本可能比 C++ 中说的要低得多”——这根本不是真的。虽然，我不确定 2003 年写这篇文章时的异常机制设计是什么。当不抛出异常时，C++ 真的没有任何成本，无论您有多少 try/catch 块以及它们在哪里。
@BJovke C++“零成本异常处理”仅意味着在不引发异常时没有运行时成本，但由于所有清理代码在异常上调用析构函数，仍然存在主要的代码大小成本。此外，虽然在正常代码路径上没有生成任何特定于异常的代码，但成本实际上仍然不是零，因为异常的可能性仍然限制了优化器（例如，发生异常时需要的东西需要保留在某处附近 -> 值可以不那么激进地丢弃 -> 寄存器分配效率较低）
a
awe

示例中的结构与 Ben M 不同。它将在内部 for 循环内扩展开销，这将导致它不能很好地比较两种情况。

对于要检查的整个代码（包括变量声明）在 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 配置的不同。

这个版本，我注意到debug版本有区别（其实比其他版本多），但是Release版本没有区别。

结论：基于这些测试，我认为我们可以说 Try/Catch 对性能的影响确实很小。

编辑：我尝试将循环值从 10000000 增加到 1000000000，然后在 Release 中再次运行以获取版本中的一些差异，结果是： 

   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 会更快。我对本的回答发表了评论。但是，与 24 位选民不同，我不喜欢这种基准测试，我认为这不是一个好的迹象。在这种情况下，代码会更快，但会一直如此吗？
这不是证明您的机器同时在执行各种其他任务吗？运行时间从来都不是一个好的衡量标准，您需要使用记录处理器时间而不是运行时间的分析器。
@Kobi：我同意，如果您要发布它作为您的程序运行速度比其他或其他东西更快的证据，这不是基准测试的最佳方法，但可以让您作为开发人员指示一种方法比另一种方法执行得更好.在这种情况下，我认为我们可以说差异（至少对于发布配置）是可以忽略的。
你没有在这里计时try/catch。您正在针对 10M 循环计时 12 次 try/catch entering-critical-section。循环的噪音将消除 try/catch 的任何影响。相反，如果您将 try/catch 放在紧密循环中，并与/不进行比较，您最终会得到 try/catch 的成本。 （毫无疑问，这种编码通常不是好的做法，但如果你想计算构造的开销，你就是这样做的）。如今，BenchmarkDotNet 是可靠执行时间的首选工具。
G
Guffa

我在一个紧密的循环中测试了 try..catch 的实际影响，它本身太小，在任何正常情况下都不会成为性能问题。

如果循环所做的工作很少（在我的测试中我做了 x++），您可以测量异常处理的影响。带有异常处理的循环运行时间大约要长十倍。

如果循环做了一些实际的工作（在我的测试中我调用了 Int32.Parse 方法），异常处理的影响太小而无法测量。通过交换循环的顺序，我得到了更大的不同......

R
RHicke

try catch 块对性能的影响可以忽略不计，但异常抛出可能相当大，这可能是您的同事感到困惑的地方。

m
mayo

虽然“预防胜于处理”，但从性能和效率的角度来看，我们可以选择 try-catch 而不是 pre-variation。考虑下面的代码： 

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
I
Isaac

try/catch 对性能有影响。

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

Here 是关于 try/catch 性能的参考（虽然没有解释它的复杂性，但它是隐含的）。看看 Throw Fever Exceptions 部分

复杂度是 O(1) 并不意味着太多。例如，如果您使用 try-catch （或者您提到循环）为经常调用的代码部分配备了，那么 O(1) 最终可能会加起来一个可测量的数字。
s
supercat

理论上，除非实际发生异常，否则 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

现在存在一系列事件，其中 statement3 可以在没有执行 statement2 的情况下执行。即使 thing2 的代码中没有任何内容可以引发异常，另一个线程也有可能使用 Interlocked.CompareExchange 注意到 q 已被清除并将其设置为 Thread.ResetAbort，然后执行 {5 } 在 statement2 将其值写入 x 之前。然后 catch 将执行 Thread.ResetAbort() [通过委托 q]，允许继续执行 statement3。这样的一系列事件当然是非常不可能发生的，但是即使发生这样的不可能事件，编译器也需要生成根据规范工作的代码。

一般来说，编译器更容易注意到忽略简单代码的机会而不是复杂代码，因此如果从不抛出异常，try/catch 很少会影响性能。尽管如此，在某些情况下，try/catch 块的存在可能会阻止优化——但对于 try/catch——本可以让代码运行得更快。

l
l33t

是的，try/catch 会“损害”性能（一切都是相对的）。就浪费的 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 是否遵循相同的规则。 TODO: Verify!

完整的测试代码 

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>();
        }
    }
}
C
Community

有关 try/catch 块如何工作的讨论，以及一些实现如何在没有异常发生时具有高开销，而一些实现为零开销的讨论，请参阅 discussion on try/catch implementation。特别是，我认为 Windows 32 位实现的开销很高，而 64 位实现则没有。

我描述的是实现异常的两种不同方法。这些方法同样适用于 C++ 和 C#，以及托管/非托管代码。我不完全知道 MS 为他们的 C# 选择了哪些，但是 MS 提供的机器级应用程序的异常处理架构使用了更快的方案。如果 64 位的 C# 实现没有使用它，我会有点惊讶。
S
Snowy

我测试了一个深度尝试捕获。 

        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

关注公众号,不定期副业成功案例分享
关注公众号

不定期副业成功案例分享

想领先一步获取最新的外包任务吗？

立即订阅

HuntsBot(狩猎机器人)，一站式外包任务、远程工作、产品创意分享与订阅平台，支持钉钉、飞书、企业微信、邮箱、Telegram机器人订阅。平台会以及时、稳定、可靠的技术把外包任务需求、远程工作机会、产品创意等推送给每一位订阅的用户。

简体中文 English

平台

支持

联系我们

在使用过程中有任何问题或建议，可以通过以下方式联系我们：

微信公众号: 火星来客

Email: huntsbot@xinbeitime.com

Copyright© 2022-2023 www.huntsbot.com 浙ICP备2022000860号-4 All Rights Reserved.