0

我刚刚阅读了一篇关于 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. 运行您的应用程序——它现在将使用优化的本机图像。

这似乎意味着您必须对进入您已发布产品的二进制文件执行指导方案。

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

4

1 回答 1

2

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

我不是专家，但据我了解，MPGO 指导数据使用方法签名（如调试符号使用的）和文件偏移量，它们在构建之间不稳定。那么问题就变成了：有多少百分比足够稳定以产生一些好处？

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

让我回到内部构建。当然，收集新的性能配置文件数据需要一段时间，因此时间敏感的内部函数（需要在构建之后立即运行）将使用部分优化的构建风格运行，因为该构建将在完全优化的构建风格之前完成数小时. 让我解释一下为什么花了这么长时间。IIRC 我们使用了配置文件“passes”，首先运行核心库场景，优化这些二进制文件，然后在以后的“端到端”场景中使用优化的核心（即服务器端 Web 服务或客户端 GUI情景）。因此，核心库将被多次分析和优化。您可以猜到，所有这些都需要时间，这就是“完全分析/优化”构建需要很长时间的原因。

我希望这可以帮到你。

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

于 2012-06-07T04:57:03.073 回答