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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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