可以在构建之间持久化MPGO数据吗？
我刚刚阅读了一个发布关于MPGO的文章 (托管概要引导优化)，描述的过程如下：
- 获得一台具有Visual 11极限测试并安装应用程序的计算机。
- 使用必要的参数运行MPGO工具(作为管理员)：
MPGO -scenario MyLargeApp.exe -AssembyList *.* -OutDir C:\Optimized\优化的IL程序集是在C:\Optimized文件夹中创建的。 - 运行NGen工具(作为管理员)，为每个应用程序DLL：
NGEN.exe myLargeApp.exe提供必要的参数 - 运行您的应用程序-它现在将使用优化的本机映像。
这似乎意味着您必须对已发布的产品中的二进制文件执行指导方案。
对我来说，在构建过程中需要手动干预是没有意义的。是否有方法执行指导方案一次，然后提交生成的数据，以便在以后的构建中自动插入到编译的程序集中？
回答 1
Stack Overflow用户
发布于 2012-06-06 20:57:03
几年前，我在微软的一个构建实验室工作，负责处理很多托管代码。让我强调一下，这是很多年前，在管理的MPGO之前是公开的。但在那时，他们会使用旧的概要数据(通常是前一天的数据，但有时长达一周)来“部分优化”一组内部二进制文件。我不能和数字说话，但如果没有好处，我们就不会这么做了。这些“部分优化”的二进制文件将只用于自动烟雾测试，并且只用于内部使用。只有完全优化的二进制文件(其配置文件数据是从同一个构建中收集的)才会被释放。
我不是专家，但据我所知，MPGO指南数据使用方法签名(比如由调试符号使用)和文件偏移量，它们在构建之间不稳定。然后问题就变成:有多少百分比是稳定的，可以得到一些好处？
让我们假设一个方法的名称更改了一个经常使用的方法。当然，旧二进制文件中的“热”页(因为该方法)在新二进制文件中找不到，经常使用的页面可能会放在优化的二进制文件的“末尾”，而这些代码是从未使用过的。在问题的另一面:有多少%的方法是从一个日常构建中重命名的？(或者更频繁地接触CI?)我猜不到1%。
让我回到内部构建。当然，收集新的perf配置文件数据需要一段时间，所以时间敏感的内部函数(需要在构建之后运行)将使用部分优化的构建风格运行，因为该构建将在完全优化的构建风格之前几个小时完成。让我解释一下为什么花了这么长时间。IIRC我们使用了概要文件'passes'，其中核心库场景首先运行，这些二进制文件被优化，而优化的核心被使用在后来的‘端到端’场景中(即服务器端web服务，或客户端GUI场景)。因此，核心库将被多次分析和优化。可以猜到，所有这些都需要时间，这就是为什么“完全分析/优化”构建需要很长时间的原因。
希望这能帮上忙。
这个问题让我想起了32位DLL重基问题。
https://stackoverflow.com/questions/10382471
复制
腾讯云开发者
