我发现这是一个相当狭窄的优化范围.惩罚存在于该范围之外,由于程序中发现的实际复杂性和设计而无法忽略,堆分配是getline示例的一个例子.尽管您尝试减少它们,但是具体的优化可能也可能并不总是适用于有问题的程序.现实世界的结构将引用别名的内存.您可以减少它,但相信您可以消除混叠(从优化器的角度来看)是不现实的.

当然,RBV可以是一件伟大的事情 – 它不适合所有的情况.即使你引用的链接也指出了如何避免大量的分配/释放.真正的程序和在其中发现的数据结构要复杂得多.

在接下来的谈话中,他继续批评使用成员函数(ref：S :: compute()).当然,有一点要拿走,但是完全避免使用这些语言功能真的是合理的,因为它使优化器的工作更容易吗？是否会总是导致更可读的程序？这些代码转换是否总是能够显着加快程序？是否需要更改变更您的代码库值得您投资的时间？有时.你能拿走一些积分,做出更明智的决定,影响你现有或将来的一些代码库？是.

有时它有助于分解你的程序将如何执行,或者在C中看起来如何.

优化器不会解决所有的性能问题,您不应该重写程序,假定您正在处理的程序是“完全死亡和断开设计”,也不应该相信使用RBV会始终导致“完全合理的性能”.您可以利用新的语言功能,并使优化器的工作更容易,尽管有很多优点往往是更重要的优化来投入时间.

考虑建议的变化是很好的理想情况下,您可以在采用这些建议之前衡量这些变更对现实执行时间的影响以及对源代码的影响.

举个例子：即使按值分配大型结构,也可能产生巨大的成本.除了运行构造函数和析构函数的成本(以及它们相关的创建/清除所获取和拥有的资源之外,如您所引用的链接中所指出的),即使避免不必要的结构副本也是简单的方式,可以节省一吨cpu如果您使用引用(如果适用)的话.结构拷贝可能与memcpy一样简单.这些都不是问题;它们出现在实际程序中,并且复杂性可以随着程序的复杂性而大大增加.减少一些内存的别名和其他价值成本的优化,是否会导致“完美合理的性能”？不总是.