有没有人看到过不同程序的真实世界数字，这些程序使用 C/C++ 编译器提供的反馈优化来支持分支预测、缓存预加载功能等。
我搜索了它，令人惊讶的是，即使是流行的解释器开发小组似乎也没有检查过效果。将 ruby、python、php 等性能提高 10% 左右应该被认为是有用的。
真的没有任何好处，还是整个开发者社区都懒得使用它？
10% 是一个不错的数字。也就是说，...
你必须真正关心性能才能走这条路。我从事的产品 (DB2) 使用 PGO 和其他侵入式和攻击性优化。其中的成本包括大量的构建时间（在某些平台上是三倍）以及开发和支持的噩梦。
当出现问题时，将优化代码中的故障位置映射回源头可能并不简单。开发人员通常不会期望不同模块中的函数最终可以合并和内联，这可能会产生“有趣”的效果。
很难追踪的指针别名问题通常也会出现在此类优化中。您还可以享受非确定性构建的额外乐趣（别名问题可能会出现在周一的构建中，直到周四才会再次消失，...）。
在这些积极的优化下，正确或不正确的编译器行为之间的界限也变得相当模糊。即使我们有内部编译器人员（字面意思），优化问题（无论是在我们的源代码还是编译器中）仍然不容易理解和解决。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
