【问题标题】:Why should I not use incremental builds for release binaries?为什么我不应该对发布二进制文件使用增量构建?
【发布时间】:2021-12-07 08:21:00
【问题描述】:

我注意到随着项目的增长,发布编译/构建时间变得比我预期(和希望的)更快的速度变慢。我决定研究如何提高编译速度。我不是在谈论初始构建时间,它涉及依赖项的编译,并且在很大程度上无关紧要。

似乎很有帮助的一件事是incremental = true 配置文件设置。在我的项目中,它似乎将 4 个以上内核的构建时间缩短了约 40%。使用更少的内核,收益会更大,因为使用incremental = true 的构建似乎并没有使用(很多)并行化。默认情况下(对于--releaseincremental = false 在单核上的构建时间比 4+ 核慢 3-4 倍。

在生产版本中避免使用incremental = true 的原因是什么?我没有看到缓存对象的二进制大小或存储大小有任何(显着)增加。我在某处读到增量构建可能会导致构建的二进制文件的性能稍差。这是唯一需要考虑的原因吗,还是有其他原因,比如稳定性等?

我知道这可能会有所不同,但是否有任何可用数据表明对实际应用程序的性能影响可能有多大?

【问题讨论】:

  • 我的理解与您所读到的一致——增量构建的优化潜力略低。这个想法是您在开发周期中使用调试构建,因此这些构建应该具有快速的编译时间。发布版本旨在构建一个版本,因此它应该具有快速的运行时间。

标签: rust compilation


【解决方案1】:

不要将增量构建用于生产版本,因为它是:

  • 不可重现(即您无法通过再次编译获得完全相同的二进制文件)并且
  • 很可能被巧妙地破坏了(增量编译比干净编译更复杂,测试更少,尤其是在启用优化的情况下)。

【讨论】:

    猜你喜欢
    • 2023-03-04
    • 1970-01-01
    • 2014-07-09
    • 1970-01-01
    • 2021-05-01
    • 1970-01-01
    • 2011-11-19
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多