Visual Studio и проблемы с компиляцией большого количества файлов

Question

Наши текущие решения / проекты объединяют несколько классов в один файл, мне сказали, что это было сделано из-за медленной компиляции в VS.

Это подтвержденная проблема и решение?

Можем ли мы разбить их на части теперь, когда мы используем систему Team VS2008? Кто-нибудь еще разделял классы на разные файлы и все еще имел хорошую производительность?

Answer 1

Я работаю в команде IDE VB.Net и могу вам сказать, что размещение всего в одном файле заставит VS работать медленнее, а не быстрее. VB.Net прекрасно работает с классами в разных файлах.

Единственный раз, когда это когда-либо будет иметь значение, - это если у вас невероятно медленный жесткий диск и файлы, которые находились на очень разных частях физических дисков (в результате чего все больше и больше нужно искать инструкции). В общем, это не должно быть проблемой, и для IDE VB.Net это будет проблемой только при первоначальном запуске. У нас есть несколько уровней кэширования, которые помогут устранить даже такие проблемы.

Вы , возможно, сможете обнаружить некоторые минимальные преимущества этого подхода, если учесть только необработанное время, необходимое для работы компилятора командной строки. ИМХО, более важными числами являются отзывчивость Visual Studio и относительное время сборки для Visual Studio. Скорость отклика VS уменьшится, если у вас будет чрезвычайно длинных файлов (что в конечном итоге произойдет, если вы поместите когда-либо класс в один файл).

Answer 2

Какое у вас оборудование?

Большое узкое место в VS заключается в том, что ему нужно читать и записывать множество маленьких файлов.

Быстрый жесткий диск или два могут улучшить производительность нагрузки!

Answer 3

Это подтвержденная проблема и подтвержденное решение. На Tech Ed в этом году они сказали, что это больше не будет проблемой в VS2010, которую вы можете скачать и попробовать.

Answer 4

Я не верю, что группирование множества классов в один файл значительно улучшит производительность сборки для обычных проектов. Должно быть безопасно разбить их на несколько файлов (по одному на класс).

Единственное исключение, с которым я столкнулся, это проекты "Веб-сайт". У меня нет никаких научных данных, но эти do , кажется, становятся медленнее с увеличением количества файлов. Чтобы исправить это, вы можете преобразовать его в проект «Веб-приложение».

Известно, что слишком большое количество проектов в решении замедляет работу VS, но это не похоже на вашу проблему.

Answer 5

Звучит так, будто вы можете попытаться убедить вашу команду заняться дизайном решения; не может быть оптимальным иметь одно гигантское решение со всеми проектами. Если время сборки действительно является проблемой, я бы лучше решил ее, разбив решение на логические части, если это возможно.

Answer 6

Я использую C #, а не VB.NET, но я никогда не сталкивался с проблемами производительности компилятора. Похоже, это какая-то преждевременная оптимизация. Мне все равно, как долго мой сервер сборки должен создавать приложение. Не жертвуйте ясностью во время сборки.