我在代码中进行了许多验证检查，如果任何检查失败，程序就会崩溃。因此，所有的检查都不太可能。
if( (msg = newMsg()) == (void *)0 )//this is more unlikely
{
panic()//crash
}
所以我在分支预测中使用了不太可能的宏提示编译器。但我没有看到任何改进（我有一些性能测试）。我使用的是gcc4.6.3。
为什么没有改善？这是因为没有其他理由吗？我应该在构建应用程序时使用任何优化标志吗？
我应该在构建应用程序时使用任何优化标志吗？
当然！即使是在最低级别进行的优化，即GCC/clang/icc的-O1，也可能胜过您的大多数优化工作。基本上是免费的，为什么不呢？
我使用的是gcc4.6.3。
GCC 4.6是旧。您应该考虑使用现代工具，除非您受到其他限制。
但我没有看到任何改进（我有一些性能测试）。
您还没有看到可见的性能改进，这在处理此类微优化时非常常见。不幸的是，用今天的硬件实现明显的改进并不容易：这是因为我们拥有比过去更快（难以置信的快）的组件。因此，节省周期不像过去那么明智了。
不过值得注意的是，顺序的微优化仍然可以使代码更快，就像在紧密循环中一样。避免暂停、分支预测失误、最大限度地提高缓存使用do在处理数据块时会有所不同。SO投票最多的问题清楚地表明了这一点。
GCC手册上甚至有这样的说明：
--内置函数：long__builtin_expect（long-exp，long-c）
您可以使用__builtin_expect为编译器提供分支预测信息一般来说，您应该更喜欢使用实际的配置文件反馈（-fprofile-arcs），因为程序员在预测程序实际执行情况方面是出了名的糟糕但是，有些应用程序很难收集这些数据。
（强调矿）
请参阅SO:上与此相关的其他答案
可能（x）和__builtin_expect（（x），1）
当一个简单的方法是使用if-else 时，我们为什么要使用__builtin_expect
等等。
搜索它：https://stackoverflow.com/search?q=__builtin_expect