Наши текущие решения/проекты имеют несколько классов, объединенных в один файл, мне говорят, что это было сделано из-за медленного времени компиляции в VS.Visual Studio и проблемы с компиляцией большого количества файлов
Является ли это подтвержденной проблемой и решением?
Можем ли мы разбить это сейчас, когда мы используем систему Team VS2008? Кто-нибудь еще разделил классы на разные файлы и все еще имел хорошую производительность?
Я работаю над командой VB.Net IDE, и могу сказать вам, что помещение всего в 1 файл заставит VS работать медленнее, а не быстрее. VB.Net отлично работает с классами в разных файлах.
Единственный раз, когда это имело бы значение, - если бы у вас был невероятно медленный жесткий диск и файлы, которые были на очень разных частях физических дисков (в результате чего все больше и больше искали инструкции). В общем, это не должно быть проблемой, и для VB.Net IDE это будет проблемой только при первом запуске. У нас есть несколько уровней кэширования, которые помогут устранить даже эти типы проблем.
Вы можете найти некоторые минимальные преимущества для этого подхода, если учесть только время, затрачиваемое на работу компилятора командной строки. ИМХО, тем более важными являются репутационность Visual Studio и относительное время сборки для Visual Studio. Ответная реакция VS будет уменьшаться, если у очень длинные файлы (это то, что в конечном итоге произойдет, если вы поместите все классы в один файл).
Это не все в 1 файле, но в каждом файле есть несколько классов, они уменьшают количество файлов с помощью нескольких классов в каждом файле. – eschneider
@escheiner, мне все еще очень сложно поверить, что это имеет значение в процессе компиляции. Как правило, более длинные файлы работают хуже, чем более короткие. – JaredPar
Сколько файлов у вас есть? у нас есть тысячи файлов и uncombined, вероятно, еще много .... – eschneider
Я использую C#, а не VB.NET, но никогда не сталкивался с проблемами производительности компилятора. Похоже, что это какая-то преждевременная оптимизация. Мне все равно, как долго мой сервер сборки должен создавать приложение. Не жертвуйте ясностью за время сборки.
Эффективность сборки очень важна! Речь идет не только о том, как долго работает сервер сборки, а о том, как быстро формировать цикл обратной связи. Тем не менее, эта оптимизация вряд ли будет очень эффективной. –
Производительность сборки - один из важнейших факторов производительности программного обеспечения. Наличие сервера сборки отличное, но это для тестирования, развертывания и качества, разработчик все равно должен отлаживать свой код локально при разработке и быстроте. – marr75
Ну, мой последний проект занимает около 20 секунд, чтобы построить для отладки (без выпуска упаковки). Из этих 20 секунд около 15 генерируют код и готовят некоторые вещи, а около 5 составляют все сборки, включая само приложение (около 100 000 строк кода). Это ничто по сравнению с тем временем, которое мои коммивояры C++ тратят на компиляцию. Я бы предпочел разделить приложение на большее количество сборок, поэтому вам не придется каждый раз перестраивать все. Я в порядке, ожидая две секунды, чтобы отладчик запустил. – OregonGhost
Похоже, что вы можете попытаться убедить свою команду задуматься о дизайне решения; возможно, не оптимально иметь одно гигантское решение со всеми проектами. Если время сборки действительно является проблемой, я бы скорее решил ее, если возможно, сломать решение до логических частей.
У них сумасшедшее количество файлов, и проекты уже слишком разбиты. Я знаю, что есть проблемы с дизайном, но это еще одна тема. – eschneider
Я не считаю, что объединение многих классов в один файл значительно улучшит производительность сборки для обычных проектов. Это должно быть безопасно разбить их на большее количество файлов (стандартный для каждого класса).
Единственное исключение, с которым я столкнулся, - это проекты «Веб-сайт». У меня нет никаких научных данных, но эти do кажутся медленнее по мере увеличения количества файлов. Чтобы исправить это, вы можете преобразовать его в проект «Веб-приложение».
Слишком много проектов в решении также известно, что VS медленно, но это не похоже на вашу проблему.
Какое у вас оборудование?
Большим узким местом с ВС является то, что ему нужно читать и писать множество небольших файлов.
Быстрый жесткий диск или два могут повысить производительность!
Мне сказали, что количество дескрипторов файлов является проблематичным для приложения и операционной системы (или их сопряжения), а не только для времени чтения и записи. Более быстрые жесткие диски, безусловно, делают для более быстрой разработки. – marr75
Я уверен, что это не самый быстрый IO, (все мои личные dev-боксы чередуются), но он должен использоваться с недавним ПК. – eschneider
Это подтвержденная проблема с подтвержденным решением проблемы. В Tech Ed в этом году они сказали, что это больше не будет проблемой в VS2010, в которую вы могли бы скачать бета-версию и попробовать.
-1 Можете ли вы привести источник для этого? –
VS2010 еще не выбрал вариант. – eschneider
-1 для не цитирования источника? Мой единственный источник был как указано: «В Tech Ed в этом году ведущий сказал, что это уже не проблема». Итак, если вы хотите продолжить исследование, скачайте бета-версию, как я предложил. – marr75
- это те проекты на C++ или .NET? –
Это проекты VB.NET. – eschneider
Кажется, нет никаких доказательств того, что это проблема и решение проблемы. По крайней мере, я не могу найти никаких ссылок на него. Я сделаю еще несколько поисков. Я думаю, что команда сделала это вместе с разделом решений/проектов и теперь не уверена в том, что повышает производительность компилятора. Теперь мой план состоит в том, чтобы предложить разделение классов и провести некоторые скамьи до и после. – eschneider