编程交流与学习--More Effective C++的学习-Item M15：了解异常处理的系统开销

不使用任何异常处理特性也要付出的代价。你需要空间建立数据结构来跟踪对象是否被完全构造（constructed）(参见条款M10)，你也需要CPU时间保持这些数据结构不断更新。这些开销一般不是很大，但是采用不支持异常的方法编译的程序一般比支持异常的程序运行速度更快所占空间也更小。

    在理论上，你不能对这些代价进行选择：异常是C++的一部分，C++编译器必须支持异常。也就是说，当你不用异常处理时你不能让编译器生产商消除这方面的开销，因为程序一般由多个独立生成的目标文件（object files）组成，只有一个目标文件不进行异常处理并不能代表其他目标文件不进行异常处理。而且即使组成可执行文件的目标文件都不进行异常处理，那么还有它们所连接的程序库呢？如果程序的任何一部分使用了异常，其它部分必须也支持异常。否则在运行时程序就不可能提供正确的异常处理。

    不过这只是理论，实际上大部分支持异常的编译器生产商都允许你自由控制是否在生成的代码里包含进支持异常的内容。如果你知道你程序的任何部分都不使用try，throw或catch，并且你也知道所连接的程序库也没有使用try，throw或catch，你就可以采用不支持异常处理的方法进行编译，这可以缩小程序的尺寸和提高速度，否则你就得为一个不需要的特性而付出代价。随着时间的推移，使用异处理的程序库开始变得普遍了，上面这种方法将逐渐不能使用，但是根据目前的软件开发情况来看，如果你已经决定不使用任何的异常特性，那么采用不支持异常的方法编译程序是一个性能优化的合理方法。同样这对于想避开异常的程序库来说也是一个性能优化的好方法，这能保证异常不会从客户端程序传递进程序库里，不过同时这样做也会妨碍客户端程序重定义程序库中声明的虚拟函数，并且不允许有在客户端定义的回调函数。

    使用异常处理的第二个开销来自于try块。粗略地估计，如果你使用try块，代码的尺寸将增加5％－10％并且运行速度也同比例减慢。这还是假设程序没有抛出异常，我这里讨论的只是在程序里使用try块的开销。为了减少开销，你应该避免使用无用的try块。

    编译器为异常规格生成的代码与它们为try块生成的代码一样多，所以一个异常规格一般花掉与try块一样多的系统开销。

    抛出异常的开销。答案是这可能会比较大。与一个正常的函数返回相比，通过抛出异常从函数里返回可能会慢三个数量级。这个开销很大。答案是令人惊恐的：一些传闻和一些基准测试（benchmarks）(参见条款M23)。事实是大部分人包括编译器生产商在异常处理方面几乎没有什么经验，所以尽管我们知道异常确实会带来开销，却很难预测出开销的准确数量。

为了使你的异常开销最小化，只要可能就尽量采用不支持异常的方法编译程序，把使用try块和异常规格限制在你确实需要它们的地方，并且只有在确为异常的情况下（exceptional）才抛出异常。如果你在性能上仍旧有问题，总体评估一下你的软件以决定异常支持是否是一个起作用的因素。如果是，那就考虑选择其它的编译器，能在C++异常处理方面具有更高实现效率的编译器。