Большое решение F # - длительное время сборки

Question

В моем текущем проекте у нас есть очень большое решение с F # -проектом. Я говорю действительно большой здесь. 70 проектов F # (файлы 480 .fs) и 4 проекта C #.

Как вы, наверное, догадались, это , начиная с , чтобы быть проблемой. Прежде всего, это требует вечного управления в Visual Studio. Но затем для сборки потребуется слишком - в прошлый раз, когда я проверял, на моей машине это заняло около 3 минут.

Я знаю, что есть (неподдерживаемые?) Способы упорядочить F # -файлы в Папках в ваших проектах , но, учитывая размер решения, я боюсь пройти через это и сделать это вручную. Также мы хотим быть уверены, что это улучшит время сборки.

Итак, теперь мой вопрос - уменьшится ли объединение в меньшее количество проектов? Скажем, мы сократили до 5-10 проектов вместо 70 на сегодняшний день.

Если нет - что мы можем сделать вместо этого? Как вы управляете проектами такого размера?

Answer 1

Я не могу говорить о больших F # решениях, но я сделал это с большими C # решениями, и время сборки заметно сократилось. например Одно решение имело ~ 100 проектов, которые мы сократили до ~ 20, а время сборки сократилось с> 10 минут до <5 минут. </p>

Преимущество было получено благодаря уменьшению проверки зависимостей и количества копий файлов из выходной папки сборки одного проекта в другую.

Answer 2

Если компиляция F # выполняется очень медленно, это может быть связано с тем, что NGEN не запускается после последних обновлений .net framework.Посмотрите на эти два вопроса stackoverflow: f # слишком медленная компиляция и F # работает очень медленно с момента последнего обновления Windows для получения дополнительной информации

Answer 3

Пробные SSD и ОЗУ мало что делают.

Зависимости между проектами могут помешать вам получить выгоду от увеличения числа одновременных сборок.

Я вас немного удивил480 файлов .fs в 70 проектах ... это примерно 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