从 Try 块“返回”的性能答案

【问题标题】：Performance of "returning" from a Try block从 Try 块“返回”的性能
【发布时间】：2010-05-12 05:41:07
【问题描述】：

如果您过早退出 try 块（例如执行 return 语句），Windows 机器上的异常处理（至少对于 C++）会降低性能，就像抛出异常一样。

但是 C# 呢？无论是通过 return 语句还是 break 语句，从 try 块中提前返回是否会影响性能？

【问题讨论】：

“如果你过早退出 try 块，Windows 机器上的异常处理（至少对于 C++）会降低性能......就像抛出异常一样。” 嗯……真的吗？这是非常令人惊讶的。数据？
密切相关（至少）：stackoverflow.com/questions/867017/performance-cost-of-try
Jeffrey Richter 的“Windows via C/C++”中介绍了 C++ 中过早退出的性能问题。
实际报价是多少？因为我看不出return-ing 出try 块和“正常”退出它之间有什么区别。异常结构中的成本通常在进入和退出时（不管如何），在现代系统中它们的成本都非常非常小，并且实际上抛出异常，这确实是非常昂贵的。（不过没关系，根据定义！这是一种特殊情况。）

【解决方案1】：

如果对性能造成影响，那就是很小的。这与捕获异常肯定没有什么相似。（即使这样也没有很多人想象的那么糟糕。）

据我所知，从 try 块返回的性能可以忽略不计。它在您的应用程序中发挥重要作用的机会基本上是 0。只需编写您可以编写的最易读的代码，然后对您的应用程序进行基准测试/分析 - 这将是获得良好性能的更好方法，而不是尝试再次猜测这类事情.

【讨论】：

【解决方案2】：

不，过早退出 try 块不会受到任何惩罚。

我计算了调用在 try 块中间返回的方法和在返回之前自然退出 try 块的方法之间的差异，并且没有可测量的差异。

拥有try 块有一点开销（大约 0.000002 毫秒），但在中间退出没有额外开销。

【讨论】：

【解决方案3】：

所有异常处理都会产生很小的性能开销 - 任何存在的 try/catch 总是需要完成额外的工作。

问题不在于它是否存在，而在于它是否相关。如果我需要捕获异常，我需要。对性能没有争议。

【讨论】：