1

我一直在研究在 Visual C++ 2013 中使用Profile Guided Optimization。我很高兴使用不同的场景作为手动步骤执行训练集，但希望最终优化的构建和链接可以在我们的 CI 构建服务器上工作。

考虑到这一点，我存储 PGO 配置文件数据库的最佳位置在哪里？将它们存储到版本控制（在我们的例子中是 Git）是最方便的地方，但我知道它们是数十甚至可能数百兆字节的二进制文件，而且这些文件不一定能很好地存储在源文件中控制系统。

或者，是否有更好的解决方案或最佳实践将 PGO 集成到我们的自动化构建中？

4

2 回答 2

0

您在这里有多种选择，您可以在考虑权衡的情况下选择其中一种。

  • 您将 PGO 用于整个代码库，还是用于某些热点或模块？您多久刷新一次数据库。
  • 使用不适当的 PGO 数据库发布某事是一个巨大的问题吗？
  • 你的项目有多大，在最坏的情况下它可以有多大
  • 在这种最坏的情况下，将 PGO 数据库存储在源代码控制中是否可以接受。

通过您的答案，您可以为自己创建一条路线。

如果您不经常刷新 PGO 数据库并且二进制大小不会破坏您的项目，您可以将它们存储在版本控制中。

如果您为每次提交重新生成它们，您可以将它们放在一个单独的存储库中，其中包括真实代码库提交 ID（在其上创建提交 PGO 配置文件数据库）作为提交消息

或者，如果您不经常生成它们，并且当您返回特定提交时，可以重新生成数据库，您可能不会存储它们，只需放入 CI 构建机器。

或者您可以围绕这些意见进行另一种组合:)

于 2017-11-16T12:00:55.190 回答
0

我们的解决方案是使用Git LFS存储 PGO 文件（另请参阅此问题）。

这种方法的优点：

  • PGO 数据库与它们关联的代码版本一起存在于存储库中
  • 数据库完全无缝地可供开发、构建和测试机器使用，无需配置外部文件存储
  • 大型二进制文件不存储在普通的 Git 存储库中，因此不会使其膨胀或使合并变得乏味。

这种方法的唯一轻微并发症是，所有机器和软件都必须支持和安装 Git LFS，从开发工作站到 CI 服务器。

于 2018-06-18T05:00:32.767 回答