与C++编码标准相关的过早优化和过早悲观

我认为,他所说的过早悲观与过早优化正好相反:根本不考虑使用哪些数据结构和算法。

过早的优化通常涉及算法的微小细节,这些细节可以在以后很好地调整,而不需要在一开始就注意。

相比之下,过早的悲观情绪与代码体系结构的高级设计有关:例如,库的一个根本低效的接口以后无法通过优化来修复,因为公共接口几乎是一成不变的。

赫伯的意思是,当你面临两个同样可读的选项时,一定要选择最有效的一个。

使用 std::vector::reserve() 或者最好的标准容器或算法不是过早优化。然而,如果不使用它们 过早的悲观 .

过早优化 当你为了一些甚至不值得的“优化”而牺牲可读性时。为此使用探查器。

编程时既有小规模的选择,也有大规模的选择。

悲观是指以“阻止编译器做好工作”的方式编写代码。一个典型的例子是,当函数非常小且简单时(例如,A{s,g}etter),不要将函数放在允许它们内联的地方。这可以使函数所花费的时间是它应该花费的时间的10倍,而且“正确”是一件非常简单的事情。

我在这个网站上发现过几次令人讨厌的事情是,当“A>>=1”同样合适时,使用“A/=2;”。如果我们知道 a 如果不是负数,那么左移和除法也有相同的效果,但即使编译器在优化除法时,它几乎总是会产生更多的代码来应对“可能是负数”的情况,在某些情况下,额外的代码可能会对性能造成实际的影响。

过早的优化是指你仅仅因为不相信编译器会做得很好而展开循环或以其他方式使代码变得更复杂——通常没有证据表明它不会做得好。

另一个例子是“不使用 std::vector “,但你自己 expandable array 因为“vector太慢了”,甚至没有使用 std::矢量 .

我倾向于认为,过早的悲观化只是对性能要求的误解,导致过早的阿片化。也就是说,你错误地认为你的代码执行得不够快或使用了太多资源(悲观主义),所以你在不必要的地方进行了优化。

随着越来越多的巨大数据集的出现,我倾向于看到更多的逆转,即缺乏足够的悲观情绪,导致选择无法扩展以满足用户需求的算法。这通常与编译器优化是对糟糕的算法选择的某种替代的信念相结合。

当通过引用时定义通过值参数 适当的

是避免的最简单的例子之一 过早悲观 。它不需要任何成本,只是成为第二天性,可以为您省去一些性能陷阱。

假设你指的是这本书- C++编码标准:101条规则、指南和最佳实践。2004年10月国际标准书号:0321113586 -项目9和25给出了几个例子:

9. 不要过早地悲观

25. 按值、(智能)指针或引用适当地获取参数