F# 大型解决方案 - 构建时间长答案

【问题标题】：F# large solution - long build timesF# 大型解决方案 - 构建时间长
【发布时间】：2012-01-11 02:53:36
【问题描述】：

在我当前的项目中，我们有一个非常大的 F#-project 解决方案。我在这里说得非常大。它有 70 个 F# 项目（480 个 .fs 文件）和 4 个 C# 项目。

你可能猜到这是开始成为一个问题。首先，在 Visual Studio 中进行管理需要很长时间。但是构建起来也花费了太的时间——上次我在我的机器上检查它花了大约 3 分钟。

我知道在Folders in your projects 中有（不支持？）组织 F# 文件的方法，但考虑到解决方案的大小，我害怕通过它并手动执行。此外，我们希望非常确定它会缩短构建时间。

那么，现在我的问题是——合并到更少的项目中会减少构建时间吗？假设我们将其减少到 5-10 个项目，而不是今天的 70 个。

如果没有 - 我们能做些什么呢？您如何管理这种规模的项目？

【问题讨论】：

您是否启用了并发构建？你的电脑有多强大？
F# 编译器比其他编译器慢很多，我没有看到很多小项目和单个大项目之间有什么不同。
您每次都需要完整构建吗？如果没有，您可以卸载您不在 VS 中处理的项目（仅在卸载之前进行完整构建）。然后，只会编译加载的项目
可以在解决方案属性窗口中设置应该构建哪些项目，而不是卸载。
工具 |选项 |项目和解决方案 |构建和运行 | ___ 最大数量 ....

标签： visual-studio-2010 f#

【解决方案1】：

我不能代表大型 F# 解决方案，但我已经使用大型 C# 解决方案做到了这一点，并且看到构建时间大幅下降。例如一种解决方案有约 100 个项目，我们将其减少到约 20 个，构建时间从 > 10 分钟缩短到

收益主要来自减少依赖检查和文件从一个项目的构建输出文件夹复制到另一个的次数。

【讨论】：

我觉得你说的很对。我删除了大约 20 个项目，并获得了足够的收益以使其可以承受。主要是由于项目之间的耦合较少。

【解决方案2】：

如果 F# 编译速度很慢，可能是因为 NGEN 在最近的 .net 框架更新后没有运行。请参阅这两个 stackoverflow 问题：f# compiling too slow 和 F# is running very slow since last round of Windows updates 了解更多信息

【讨论】：

可悲的是，我们的各个项目运行得像闪电一样快。因此，如果我自己编译一个小项目（无依赖关系），它会立即完成。不过听起来是个好主意

【解决方案3】：

尝试过的 SSD 和 RAM 驱动器没有多大作用。

项目之间的依赖关系可能会阻止您从增加并发构建数量中获得任何收益。

我有点惊讶您在 70 个项目中有 480 个 .fs 文件......每个项目大约有 6-7 个文件，这并不多。无论如何，即使不是出于性能原因，也可能值得一看——无论哪种方式都可能存在（将？）设计问题。但是构建时间似乎与每个项目的文件（或 LOC）数量一致，因此您可能不会按自己的意愿进行压缩。

我个人因此失去了每次清洁和重建的习惯。

编辑：在 Expert F# 中找到了一个我认为值得一提的相关注释：

.NET assemblies often contain a large amount of code. For example, a single assembly may contain as 
many as 50 or 100 F# source code files. Having many small assemblies may seem tempting, such as to improve 
compilation times during development, but can lead to difficulties when you’re managing updates and can be 
confusing to end users. Large assemblies are easier to version: you have to update only one component, and you 
can package multiple updates into a single new version of the DLL

【讨论】：

是的——终于有人敢说这件事了……我认为你是对的，但我还不确定。 LOCs 可能是最重要的事情。但是 - 对于 Vs2010 中的纯可读性和管理，我们可能会尽量减少项目数量
是的，您可能不会从合并项目中获得显着的构建时间改进，这是一个相当艰难的实验。我什至不确定将代码大量重构为高阶函数会产生改进或降级。
@DavidGrenier：FWIW，每个项目 6-7 个文件对我来说听起来很合理。