可以在构建之间保留MPGO数据吗？

Question

我刚刚阅读了post about MPGO（托管配置文件引导优化），所描述的流程是：

1. 获取安装了Visual Studio 11 Ultimate Beta并安装了您的应用程序的计算机。
2. 使用必要参数运行MPGO工具（作为管理员）：
   MPGO -scenario MyLargeApp.exe -AssembyList *.* -OutDir C:\Optimized\ 优化的IL程序集在C:\Optimized文件夹中创建。
3. 使用每个应用程序DLL的必要参数运行NGen工具（作为管理员）： NGEN.exe myLargeApp.exe
4. 运行您的应用程序 - 它现在将使用优化的原生图像。

这似乎暗示您必须对发布到您发布的产品的二进制文件执行指导方案。

对我来说，在构建过程中需要手动干预是没有意义的。有没有办法执行一次引导方案，然后提交生成的数据，以便在将来的构建中自动插入到已编译的程序集中？

Answer 1

多年前，我在Microsoft的一个构建实验室工作，处理了大量托管代码。让我强调，这是多年前的事情，在管理的MPGO公开之前。但是那时他们会使用旧的个人资料数据（通常是从前一天开始，但有时长达一周）来“部分优化”一组内部二进制文件。我不能说数字，但如果它没有一些好处，我们就不会这样做。那些“部分优化”的二进制文件仅用于自动烟雾测试，仅供内部使用。只会发布完全优化的二进制文件（其配置文件数据是从同一版本中收集的）。

我不是专家，但根据我的理解，MPGO指导数据使用方法签名（如调试符号所使用的）和文件偏移，这些在构建之间不稳定。然后问题变成：什么百分比足够稳定以获得一些好处？

让我们说一个方法名称会改变一个经常使用的方法。然后，当然，旧二进制文件中的“热门”页面（因为该方法）将无法在新二进制文件中找到，并且经常使用的页面可能会放在优化二进制文件的“末尾”使用从未使用过的代码。硬币的另一面：从每日构建中重命名的方法的百分比是多少？ （或者甚至更频繁地使用CI？）我猜不到1％。

让我跳回内部版本。当然，收集新的perf配置文件数据需要一段时间，因此时间敏感的内部函数（需要在构建之后运行）将使用部分优化的构建风格运行，因为该构建将在完全优化的构建风格之前完成几个小时。让我解释为什么花了这么长时间。 IIRC我们使用了配置文件'pass'，其中核心库场景首先运行，这些二进制文件被优化，优化的核心用于后来的“端到端”场景（即服务器端Web服务或客户端GUI）场景）。因此核心库将被多次分析和优化。正如你猜测的那样，所有这些都需要时间，这就是“完全分析/优化”构建需要很长时间的原因。

我希望这很有帮助。

P.S。这个问题让我想起了32-bit DLL rebase issues。