Performance 编译器所做的配置文件引导优化是否会显著损害配置文件数据集未涵盖的情况？ 这个问题不是针对C++的，像java RE这样的运行时可以即时进行轮廓引导优化，我也感兴趣。

MSDN是这样的：

我插入我的程序并在分析器下运行，然后

编译器使用探查器收集的数据自动重新组织分支和循环，从而减少分支预测失误，并且通常将运行代码紧凑地放置以改进其局部性

显然，分析结果将取决于使用的数据集

通过正常的手动评测和优化，我会发现一些瓶颈并改进这些瓶颈，并且可能会保留所有其他代码不变。PGO似乎以降低很少运行的代码的速度为代价来改进经常运行的代码

---

现在，如果程序在现实世界中看到的另一个数据集上经常运行速度较慢的代码，该怎么办？与未使用PGO编译的程序相比，程序性能会降低吗？性能降低的程度有多严重？换句话说，PGO是否真的提高了评测数据集的代码性能，并可能恶化其他数据集的性能？有真实数据的真实示例吗？

PGO肯定会影响运行频率较低的代码的运行时间。毕竟，您正在修改某些函数/块的局部性，这将使现在组合在一起的块更易于缓存

我所看到的是团队确定了他们的高优先级场景。然后，他们运行这些程序来训练优化分析器并测量改进。您不想在PGO下运行所有场景，因为如果您这样做，您可能不想运行任何场景

正如在所有与性能相关的方面一样，在应用它之前，您需要进行测量。了解最常见的场景，看看它们是否通过使用PGO培训得到了改善。还可以测量不太常见的场景，看看它们是否有任何倒退。

免责声明：我在PGO方面做的最多的事情就是阅读它，并用一个示例项目尝试一次。下面的很多内容都是基于我在“非PGO”优化和有根据的猜测方面的经验。TL；下面是博士

列出了PGO完成的优化。让我们逐一查看它们（按影响分组）：

内联–例如，如果存在一个函数a经常调用函数B，而函数B相对较小，那么配置文件引导优化将内联函数a中的函数B

寄存器分配–使用配置文件数据进行优化可获得更好的寄存器分配

虚拟调用推测–如果虚拟调用或通过函数指针的其他调用经常以某个函数为目标，则配置文件引导的优化可以将有条件执行的直接调用插入到经常以该函数为目标的函数中，并且直接调用可以内联

无论某些优化是否奏效，这显然改善了预测。对于未分析的代码路径，没有直接的权衡

---

基本块优化–基本块优化允许将在给定帧内临时执行的常用基本块放置在同一组页面（位置）中。这样可以最大限度地减少使用的页面数量，从而最大限度地减少内存开销

函数布局–根据调用图和分析的调用方/被调用方行为，倾向于沿着相同执行路径的函数被放置在同一部分中

死代码分离–在分析过程中未调用的代码被移动到一个特殊的节中，该节附加到节集的末尾。这有效地避免了经常使用的页面中的此部分

裕利安怡代码分离–异常执行的裕利安怡代码通常可以移动到一个单独的部分，此时配置文件引导的优化可以确定异常仅在异常情况下发生

所有这些都可能会减少非分析代码路径的局部性。根据我的经验，如果此代码路径有一个超过一级代码缓存（甚至可能超过二级代码缓存）的紧密循环，则影响将是明显或严重的。这听起来很像PGO配置文件中应该包含的路径：）

死代码分离可能会产生巨大的影响（两种方式），因为它可以减少磁盘访问

如果您依赖异常的快速性，那么您就做错了

---

大小/速度优化–程序花费大量时间的功能可以针对速度进行优化

现在的经验法则是“默认情况下优化大小，只在需要时优化速度（并验证它是否有帮助）”。原因再次是代码缓存-在大多数情况下，较小的代码也将是较快的代码，因为代码缓存。因此，这种类型的自动执行您应该手动执行的操作。与全局速度优化相比，这只会在非常不典型的情况下减慢未分析的代码路径（“奇怪的代码”）“或具有异常缓存行为的目标计算机）

---

条件分支优化–通过值探测，配置文件引导优化可以发现switch语句中的给定值是否比其他值使用得更频繁。然后可以从switch语句中提取该值。对于if/else指令也可以这样做，优化器可以对if/else进行排序，以便根据哪个块更频繁地为真，将if或else块放在第一位

除非你提供了错误的PGO信息，否则我也会将其归入“改进预测”项下

这会带来很多好处的典型情况是运行时参数/范围验证和在正常执行中不应采用的类似路径

最重要的情况是：

if (x > 0) DoThis() else DoThat();

在相关的紧密循环中和profili