CODEWITHSUNDEEP
visual-studio-2010f#
Marcus Hammarberg
Marcus Hammarberg

Reputation: 4822

F# large solution - long build times

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?

Upvotes: 3

Views: 645

Answers (3)

David Grenier
David Grenier

Reputation: 1110

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

Upvotes: 1

Luc C
Luc C

Reputation: 1153

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

Upvotes: 1

Leaf Garland
Leaf Garland

Reputation: 3687

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.

Upvotes: 2

Related Questions