F# large solution - long build times

Question

In my current project we have a very big solution with F#-project. I'm talking really big here . Its 70 F# projects (480 .fs files) and 4 C# projects.

As you probably guess this is starting to be a problem. First of all it takes forever to manage in Visual Studio. But then it also takes too long to build - last time I checked it took ca 3 minutes on my machine.

I know that there are (unsupported?) ways to organize F#-files in Folders in your projects but given the size of the solution I dread going through it and do that manually. Also we want to be pretty sure that it will improve the build time.

So, now my question - will merging into fewer projects decrease build time? Say that we get it down to 5-10 projects instead of 70 as of today.

If not - what can we do instead? How do you manage projects of this size?

Have you enabled concurrent builds? How powerful are your computers? — Richard, Dec 01 '11 at 11:04
F# compiler is significantly slower than other compilers, I have not seen a different between many small projects and a single large project. — Ramon Snir, Dec 01 '11 at 11:04
Do you require a full build each time ? If not, you can unload projects you are not working on in VS (just to a full build before the unload). Then, only loaded projects will be compiled — Steve B, Dec 01 '11 at 11:12
Instead of unloading, it is possible to set which projects should be build in the Solution Properties window. — Ramon Snir, Dec 01 '11 at 11:14
@steveB and - we've tried to have local solutions that include different projects for different purposes to minimize build time. But that was a lot of ... administration of solution files — Marcus Hammarberg, Dec 01 '11 at 11:26
Tools | Options | Projects and Solutions | Build and Run | `___` maximum number .... — Richard, Dec 01 '11 at 11:44
@Richard yeah - found it now (was on my lunch before). It was sadly set to 4 (the number of cores I have here) — Marcus Hammarberg, Dec 01 '11 at 11:48
@MarcusHammarberg - you might not be CPU bound yet, I would try setting it higher — John Palmer, Dec 01 '11 at 11:58
@Marcus Hammarberg: that's why unloading projects can be a good idea. You still works with only one solution, but only with some projects — Steve B, Dec 01 '11 at 12:16
See http://www.hanselman.com/blog/HackParallelMSBuildsFromWithinTheVisualStudioIDE.aspx "I've got 900 Projects and Visual Studio is Slow, what's the deal?" — Mauricio Scheffer, Dec 01 '11 at 14:49
[This question](http://stackoverflow.com/q/152053) may be of interest to you. — Benjol, Dec 02 '11 at 05:39
@7sharp9 yeah my thinking exactly... Not my solution, just inherited it — Marcus Hammarberg, Dec 02 '11 at 09:14
@MauricioScheffer read and tried hanselman tip - not any major improvements — Marcus Hammarberg, Dec 02 '11 at 09:15
@MauricioScheffer - and yes 74 projects is just ridiculous - but hey, it's dropped in my lap. I'm just trying to clean it up — Marcus Hammarberg, Dec 02 '11 at 09:29

score 2 · Accepted Answer · answered Dec 01 '11 at 22:05

2

I can't speak for large F# solutions but I've done this with large C# solutions, and seen build times drop massively. e.g. One solution had ~100 projects which we reduced to ~20 and build times dropped from > 10 minutes to < 5 minutes.

The gain came mainly from reducing dependency checking and the number of times files were copied from one project's build output folder to another.

answered Dec 01 '11 at 22:05

Leaf Garland

3,647
18
18

I think you're quite right. I removed circa 20 projects and gained enough to make it bareable. Mostly due to less coupling between projects. – Marcus Hammarberg Dec 13 '11 at 13:17

David Grenier · Answer 2 · 2012-01-10T18:53:36.257

Tried SSD & RAM drives doesn't do much.

Dependencies between projects might prevent you from gaining anything from increasing the number of concurrent build.

I'm a bit surprised you have 480 .fs files in 70 projects... that amounts to about 6-7 files per project which isn't much. It might be worth looking over that anyway even if it's not for performance reason - one can have (will?) design issues either way. But build time seems to be consistent with the number of files (or LOCs) per project so you may not squeeze as much as you'd want there.

I personally lost the habit of cleaning and rebuilding every time for that reason.

Edit: Found a related note in Expert F# which I thought was worth mentionning:

.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

yeah - finally someone who dare say something about that... I think you are right but I'm not completely sure yet. LOCs is probably the most important thing. But - for pure readability and management in Vs2010 we might minimize the number of projects — Marcus Hammarberg, Dec 01 '11 at 15:01
Yes, you may not get significant build time improvements from merging projects and it's a rather tough experiment. I'm not even sure heavily refactored code into higher order functions would yield improvements or degradation. — David Grenier, Dec 01 '11 at 21:12
@DavidGrenier: FWIW, 6-7 files per project sounds quite reasonable to me. — J D, Dec 02 '11 at 01:12

score 1 · Answer 3 · edited May 23 '17 at 12:01

1

If F# compilation is very slow it may be due to NGEN not having run after recent .net framework updates. See these two stackoverflow questions: f# compiling too slow and F# is running very slow since last round of Windows updates for more information

edited May 23 '17 at 12:01

Community

1
1

answered Dec 01 '11 at 16:28

Luc C

1,133
8
22

Sadly our individual projects runs fast as lightning. So if I compile a small project by itself (no dependencies) it's done in no-time. Sounded like a great idea though – Marcus Hammarberg Dec 02 '11 at 09:20

F# large solution - long build times

3 Answers3