#c# #io #compilation
#c# #io #Сборник
Вопрос:
У нас были дебаты на работе относительно структуры проекта .net и связанной с этим рабочей нагрузки компилятора.
Я стою в углу, чем больше у вас .net-проектов, тем больше зависимостей между проектами у вас есть, тем больше работы вы просите выполнить компилятор. Мой аргумент сосредоточен вокруг количества операций ввода-вывода, задействованных во время компиляции, когда есть больше проектов. Кто-то на работе предполагает, что количество проектов не связано со временем компиляции. Излишне говорить, что мне пока пришлось прикусить язык, поскольку у меня нет эмпирических данных, просто опыт, который говорит мне, что я прав.
Хотя у меня есть много других мнений о многих причинах разделения кода на разные проекты .net, которые обычно являются ошибочными или не логичными, я на самом деле просто пытаюсь найти авторитетные эмпирические доказательства, которые либо поддержат меня, либо скажут мне, что я неправ.
Я огляделся и изо всех сил пытаюсь найти недавнюю (или иную) всеобъемлющую статью об этом.
Любая помощь по этому вопросу будет с благодарностью оценена.
Спасибо, Тим
Редактировать: во избежание сомнений я говорю о том же объеме кода, разделенном на большее количество проектов, а не о большем количестве кода над большим количеством проектов.
Комментарии:
1. Больше проектов = больше кода = больше компиляции… Насколько это сложно?
2. также больше разрешения зависимостей; нам пришлось сократить количество проектов, поскольку наш сервер сборки занимал слишком много времени. На самом деле это довольно легко доказать: настройте два демонстрационных решения и время их создания.
3. Вы имеете в виду «тот же код, разделенный на большее количество проектов»? Я думаю, это явно подразумевается (вопрос слишком очевиден, чтобы задавать его иначе), но вы никогда не знаете.
4. Это слишком широко для SO… Нет замены для измерения вашего конкретного случая и принятия решения. Примечания, о которых стоит подумать: чтения с диска кэшируются — если на ваших машинах нет небольшого объема оперативной памяти, чтение одной и той же зависимости несколько раз не будет иметь большого значения, единственный реальный способ ускорить процесс — это не делать их 🙂 — если решение слишком велико, разбивая его на несколько отдельных сборок и подталкивая зависимости кдругие (например, через NuGet), вероятно, ускорят каждую конкретную сборку.
5. производительность (в данном случае скорость компиляции) не может быть определена с помощью мысли, только путем измерения. Итак, настройте несколько тестов и измерьте