Дуже повільний час компіляції у Visual Studio 2005


132

Ми отримуємо дуже повільний час компіляції, який може зайняти більше 20 хвилин на двоядерних 2GHz, 2G Ram машинах.

Багато цього пояснюється розміром нашого рішення, яке зросло до 70+ проектів, а також VSS, який є самим горловиною для пляшок, коли у вас багато файлів. (Заміна VSS не є варіантом на жаль, тому я не хочу, щоб це переходило в базу VSS)

Ми дивимося на об'єднання проектів. Ми також розглядаємо наявність декількох рішень, щоб досягти більшого відокремлення проблем та швидшого часу складання кожного елемента програми. Це, як я бачу, перетвориться на пекло DLL, коли ми намагатимемося підтримувати речі синхронно.

Мені цікаво дізнатися, як інші команди вирішили цю проблему масштабування, що ви робите, коли база вашого коду досягає критичної маси, яку ви витрачаєте половину дня, дивлячись на рядок стану доставки компілюючих повідомлень.

ОНОВЛЕННЯ Я знехтував згадати це рішення C #. Дякую за всі пропозиції C ++, але минуло кілька років, як мені довелося переживати за заголовки.

Редагувати:

Приємні пропозиції, які допомогли поки що (не кажучи, що немає інших приємних пропозицій нижче, лише те, що допомогло)

  • Новий ноутбук 3 ГГц - потужність втраченої утилізації творить чудеса під час бігу до управління
  • Вимкнути антивірус під час компіляції
  • 'Відключення' від VSS (власне мережі) під час компіляції - я можу змусити нас повністю видалити інтеграцію VS-VSS і дотримуватися використання інтерфейсу VSS

Все ще не зривати хропіння через компіляцію, але кожен біт допомагає.

Оріон згадував у коментарі, що генерики також можуть мати гру. З моїх тестів, схоже, є мінімальна ефективність, але недостатньо висока, щоб впевнитись - час компіляції може бути невідповідним через активність диска. Через обмеження в часі мої тести не включали стільки дженериків чи стільки коду, скільки було б у живій системі, щоб вони могли накопичуватися. Я б не уникав використання дженериків там, де вони повинні використовуватися, лише для часу компіляції

РОБОТА

Ми перевіряємо практику побудови нових областей додатку в нових рішеннях, імпортуємо в найновіші DLL, якщо потрібно, інтегруючи їх у більш широке рішення, коли ми з ними задоволені.

Ми також можемо виконати їх із існуючим кодом, створивши тимчасові рішення, які просто інкапсулюють сфери, над якими нам потрібно працювати, і викинувши їх після реінтеграції коду. Нам потрібно зважити час, який знадобиться для реінтеграції цього коду до часу, який ми отримуємо, не маючи Rip Van Winkle, як досвід швидкого перекомпіляції під час розробки.


Нічого собі, я думав, що 20 секунд компіляції були неприємно довгими.
Jared Updike

Постарайтеся пропонувати декілька рішень, якщо це взагалі можливо, оскільки рефакторинг стає набагато складніше.
Ян Рінроуз

Ви можете використовувати VSS поза візуальною студією, щоб у вас не було накладних витрат на візуальну студію, що розмовляла з VSS.
Ян Рінроуз

Як щодо ресурсів? Я можу уявити, що вони сповільнюють процес. Я бачив комерційне програмне забезпечення з файлами EXE розміром компакт-дисків, які ви починаєте з компакт-диска (не налаштування). Вони були сповнені відео, аудіо та фотографій. Отже, програмне забезпечення було саме цим файлом ....
Bitterblue

Відповіді:


74

Команда Chromium.org перерахувала кілька варіантів прискорення збірки (на даний момент приблизно на півдорозі вниз по сторінці):

У порядку зменшення швидкості:

  • Встановіть виправлення Microsoft 935225 .
  • Встановіть виправлення Microsoft 947315 .
  • Використовуйте справжній багатоядерний процесор (наприклад, Intel Core Duo 2; не Pentium 4 HT).
  • Використовуйте 3 паралельних побудови. У Visual Studio 2005 ви знайдете цю опцію в меню Інструменти> Параметри ...> Проекти та рішення> Створити та запустити> максимальну кількість паралельних збірок проектів .
  • Вимкніть антивірусне програмне забезпечення для файлів .ilk, .pdb, .cc, .h і перевіряйте лише наявність вірусів на модифікацію . Вимкнути сканування каталогу, де перебувають ваші джерела. Не робіть нічого дурного.
  • Зберігайте та будуйте код Chromium на другому жорсткому диску. Це не дійсно пришвидшить збірку, але принаймні ваш комп'ютер буде залишатися чутливим, коли ви робите gclient sync або збирання.
  • Регулярно дефрагментуйте ваш жорсткий диск.
  • Вимкнути віртуальну пам'ять.

30
Під відключенням віртуальної пам’яті я припускаю, що ви маєте на увазі вимкнення swap, відключення віртуальної пам’яті потребує перезапису всієї ОС; p
Джозеф Гарвін

9
Це виглядає як відповідь, спрямована на те, що C ++ будує не C # будує
Ян Рінроуз

2
Ти маєш рацію! Хоча я повинен зазначити, що я відповів, перш ніж він вказав C #, а деякі виправлення все ще застосовуються.
Нейт

* Зберігайте проект на SSD диск * Відключити вікна індексації (у файловому менеджері, папки правильне рішення, натисніть властивості-> Додатково, зніміть галочку «Дозволити файли ... індексуються ...»)
NOS

+1 Якщо у вас достатньо оперативної пам’яті, вони зберігають проект на диску RAM. Це може значно підвищити продуктивність до 50-70%. перевірити codeproject.com/Articles/197663/Speed-up-Visual-Studio-Builds для отримання додаткової інформації
Arjun Vachhani

58

У нас майже 100 проектів за одне рішення, а час розробки розробника - лише секунди :)

Для місцевого розвитку будує ми створили Visual Studio надбудови , що зміни Project referencesв DLL referencesі розвантажує небажані проекти (і можливість перемикати їх назад, звичайно).

  • Створіть все наше рішення один раз
  • Вивантажте проекти, над якими ми зараз не працюємо, і змініть всі посилання на проекти на посилання на DLL.
  • Перед реєстрацією змінити всі посилання назад з DLL на посилання на проект.

Наші розробки зараз займають лише кілька секунд, коли ми працюємо над кількома проектами одночасно. Ми також можемо налагоджувати додаткові проекти, оскільки вони посилаються на DLL-файли налагодження. Зазвичай інструмент займає 10-30 секунд, щоб здійснити велику кількість змін, але робити це не потрібно так часто.

Оновлення травня 2015 року

Угода, яку я зробив (у коментарях нижче), полягала в тому, що я випущу плагін у Open Source, якщо він виявить достатній інтерес. Через 4 роки у нього лише 44 голоси (а Visual Studio зараз має дві наступні версії), тому наразі це проект з низьким пріоритетом.


2
Також застосовували цю техніку, в рішенні було 180 проектів. Це дуже допомогло. Ви навіть можете скористатися командним рядком для створення всього рішення `devenv.exe / побудувати ваше рішення / takealookatthedoc`` ... так що ви працюєте лише з кількома проектами, і коли потрібно, ви перекомпілюєте все рішення в cmd-рядку (після отримати останню версію для зразка)
Стів Б

Чи є у вас посилання, які описують, як це робиться? Я не маю на увазі писати плагін VS. Вірніше, описані конкретні завдання
Даніель Дайсон

@Daniel Dyson: Наскільки детально вам потрібно знати? Все зводиться до 1) завантаження будь-яких не завантажених проектів 2) ітерації рішення / ієрархії проекту / 3) пошуку проектів із посиланням на інші проекти 4) зміни "обраних" посилань на посилання DLL (з правильними шляхами підказки), а потім 5) вивантаження небажаних проектів. "Вибрано" або через меню вмісту (тобто вибраних проектів) або через дерево прапорців для вибору елементів.
Пройшов кодування

Дякую. Цього має бути достатньо, щоб розпочати мене.
Даніель Дайсон

1
@HiTechMagic Ах, шкода, що це чую. Але так, звільнивши це як відкритий код, ми можемо всім допомогти. Будь ласка, опублікуйте посилання github тут, якщо ви його відпустите.
georgiosd

24

У мене було подібне питання щодо вирішення 21 проекту та 1/2 мільйонів LOC. Найбільша різниця полягала в тому, щоб отримати швидші жорсткі диски. З монітора продуктивності "Сер. Черга диска 'помітно підскочила б на ноутбуці, вказуючи на жорсткий диск - горлечко пляшки.

Ось деякі дані за загальний час відновлення ...

1) Ноутбук, Core 2 Duo 2 ГГц, 5400 RPM Drive (не впевнений у кеші. Був стандартним Dell inspiron).

Час перебудови = 112 секунд.

2) Настільний (стандартний випуск), Core 2 Duo 2,3 ГГц, одномісний кеш-пам'ять 7200RPM 8MB.

Час перебудови = 72 секунди.

3) Настільний Core 2 Duo 3Ghz, одиночний WD Raptor 10000 RPM

Час перебудови = 39 секунд.

Привід 10 000 об / хв не можна занижувати. Будівлі, де значно швидше плюс усе інше, як показ документації, використання файлового провідника було помітно швидше. Це було великим підвищенням продуктивності за рахунок прискорення циклу збирання коду.

З огляду на те, що компанії витрачають на зарплату розробникам, божевільно, скільки вони можуть витратити, купуючи, оснащуючи їх тими ж ПК, якими користується портьє.


4
Як би SSD порівнювався з грабіжником. Ще швидше я
здогадуюсь

4
Так. Мій ноутбук із Intel X25M є швидшим у всіх аспектах, ніж мій робочий стіл із WD Raptor.
CAD блокується

4
Це може здатися дивним, але наразі не варто вкладати гроші в привід 10000 об / хв. Причина полягає в тому, що кращі 7200 об / хв швидші на зовнішній оправі. Отже, що потрібно зробити, це створити невеликий розділ. Перший розділ знаходиться на зовнішній оправі, цей розділ буде швидшим, ніж 7200 об / хв, плюс у вас ще є місце для другої великої секції для зберігання речей.
темнок

2
@cornelius: чи можу я отримати посилання, що деталізує вашу думку? Єдиний спосіб, коли зовнішній ободок 7200 міг би бути швидшим, ніж зовнішній ободок 10000, це було б, якби 7200-ті мали тенденцію мати радіус, який, можливо, міг би бути, але насправді цей трюк був би свого роду злом і не приносив би користі для решти накопичувача жорсткого диска на 7200, що знаходиться нижче радіусу рівноваги, при якому два накопичувачі мають однакову тангенціальну швидкість.
eremzeit

2
Я з CADbloke. Ми використовували грабіжників до минулого року, коли ціна на SSD знизилася до того, що ми використовуємо лише SSD для основних дисків на своїх ноутбуках / настільних комп'ютерах. Зростання швидкості є фантастичним і легко є єдиним найбільшим фактором у тому, скільки часу потрібно для складання наших рішень.
NotMe

16

Для побудови C # .NET ви можете використовувати .NET Demon . Це продукт, який переймає процес збирання Visual Studio, щоб зробити його швидшим.

Це робиться, аналізуючи внесені вами зміни та будує лише той проект, який ви насправді змінили, а також інші проекти, які фактично покладалися на внесені вами зміни. Це означає, що якщо ви змінюєте лише внутрішній код, потрібно створити лише один проект.


Це не те, що VS вже робить? Або ви маєте на увазі невідповідні зміни, як-от коментарі тощо, відкидаються?
nawfal

1
Redgate, на жаль, припинив роботу над демоном .net, тому він не працює над VS 2013
Роберт Іванч

14

Вимкніть антивірус. Це додає віків до часу компіляції.


2
... для папки коду / компіляції. Перетворення захисту AV як правило покриття ковдрою не є геніальною ідеєю. : o)
Бретт Рігбі

5
Вам не потрібно це вимикати, зазвичай правильно їх налаштувати. Додайте винятки до типів файлів, з якими працює компілятор / посилання. У деяких антивірусних пакетах ці винятки додано за замовчуванням, в деяких - ні.
темнок

@cornelius Яка правильна антивірусна конфігурація? Чи можете ви надати деталі? (можливо, в окремому питанні?)
Павло Радзівіловський

@Pavel: Добре, виключіть типи файлів, з якими працює компілятор, для C ++, які були б такими, як .o, .pdb, .ilk, .lib, .cpp, .h. Також деяке антивірусне програмне забезпечення (наприклад, Avira AntiVir) дозволяє налаштувати сканування файлів у режимі читання, запису чи обох. Налаштування його для сканування при прочитанні забезпечить 99% захист.
темнок

12

Використовуйте розподілену компіляцію. Xoreax IncrediBuild може скоротити час складання до декількох хвилин.

Я використовував це для величезного рішення C \ C ++, для складання якого зазвичай потрібно 5-6 годин. IncrediBuild допомогла скоротити цей час до 15 хвилин.


Встановлення IncrediBuild на декількох запасних комп'ютерах скорочувало час компіляції в 10 чи більше разів для нашого проекту C ++, майже не вимагаючи адміністрування.
Штіфель

мав той самий досвід аку ... однак посилання все ж таки було проблемою хе-хе
Пол Керролл

Якщо ви їдете цим маршрутом, тоді просто мати пару виділених серверів побудови. Однак схоже, що ОП намагалася виправити час збирання на локальних розроблювальних машинах.
NotMe

11

Інструкції щодо скорочення часу збирання Visual Studio до декількох секунд

На жаль, Visual Studio недостатньо розумний, щоб відрізнити зміни інтерфейсу збірки від невластивих змін коду. Цей факт, поєднуючись із великими переплетеними рішеннями, іноді може створити ідеальну бурю небажаних «повноцінних складок» майже кожного разу, коли ви змінюєте один рядок коду.

Стратегія подолати це - відключити автоматичні побудови еталонного дерева. Для цього використовуйте "Менеджер конфігурацій" (Менеджер конфігурації / Конфігурація ... потім у спадному меню "Конфігурація активного рішення" виберіть "Нове"), щоб створити нову конфігурацію збірки під назвою "ManualCompile", яка копіює з конфігурації налагодження, але роби не встановіть прапорець "Створити нові конфігурації проекту". У цій новій конфігурації збірки зніміть прапорці для кожного проекту, щоб жоден з них не будувався автоматично. Збережіть цю конфігурацію, натиснувши «Закрити». Ця нова конфігурація збірки додана у файл рішення.

Ви можете переходити від однієї конфігурації збірки до іншої за допомогою спадного меню конфігурації збірки у верхній частині екрана IDE (тієї, яка зазвичай показує або "Налагодження" або "Випуск"). Ефективно ця нова конфігурація збірки ManualCompile непридатна для параметрів меню Build для: "Build Solution" або "Rebuild Solution". Таким чином, коли ви перебуваєте в режимі ManualCompile, ви повинні вручну скласти кожен проект, який ви змінюєте, що можна зробити, клацнувши правою кнопкою миші на кожному впливовому проекті в Провіднику рішень, а потім виберіть 'Build' або 'Rebuild'. Ви повинні бачити, що ваш загальний час складання становитиме лише секунди.

Щоб ця стратегія спрацювала, необхідно, щоб файли VersionNumber, знайдені у файлах AssemblyInfo та GlobalAssemblyInfo, залишалися статичними на машині розробника (не під час збору версій, звісно), і щоб ви не підписували ваші DLL.

Потенційний ризик використання цієї стратегії ManualCompile полягає в тому, що розробник може забути скласти необхідні проекти, і коли вони запускають налагоджувач, вони отримують несподівані результати (не в змозі приєднати налагоджувач, файли не знайдені тощо). Щоб цього уникнути, можливо, найкраще використовувати конфігурацію збірки «Налагодження» для компіляції більших зусиль із кодування та використовувати лише конфігурацію збірки ManualCompile під час тестування блоку або для швидких змін, що мають обмежений обсяг.


8

Якщо це C або C ++, а ви не використовуєте заздалегідь складені заголовки, вам слід.


Якщо заздалегідь складені заголовки працюють для вас, то це хороший трюк, але вони працюють лише у тому випадку, якщо ви зможете встановити сильний загальний підмножина заголовків, які рідко змінюються. Якщо вам доведеться попередньо компілювати заголовки більшу частину часу, який ви будуєте, ви нічого не економите.
Tom Swirly

7

У нашому головному рішенні було 80+ проектів, на розбудову яких було потрібно від 4 до 6 хвилин, залежно від того, на якій машині працював розробник. Ми вважали це занадто довгим: для кожного тесту він дійсно з'їдає ваші FTE.

Тож як швидше збільшити час збирання? Як вам здається, ви вже знаєте, що кількість проектів справді шкодить будівельному часу. Звичайно, ми не хотіли позбуватися всіх наших проектів і просто кидали всі вихідні файли в один. Але у нас були деякі проекти, які ми все-таки могли поєднати: Оскільки кожен проект "Репозиторій" у рішенні мав власний проект "єдиний тест", ми просто об'єднали всі проекти "єдиний тест" в один проект глобального тестування. Це скоротило кількість проектів з приблизно 12 проектами і якимось чином заощадило 40% часу на створення всього рішення.

Однак ми думаємо про інше рішення.

Ви також намагалися налаштувати нове (друге) рішення з новим проектом? Це друге рішення повинно просто включати всі файли, використовуючи папки рішення. Тому що ви можете бути здивовані, побачивши час створення цього нового рішення-з-просто-одним-проектом.

Однак робота з двома різними рішеннями потребує ретельного розгляду. Розробники можуть бути схильні фактично працювати у другому рішенні і повністю нехтувати першим. Оскільки першим рішенням проектів 70+ стане рішення, яке піклується про вашу ієрархію об’єктів, це має бути рішенням, де ваш buildserver повинен виконувати всі ваші тестові одиниці. Отже, сервер для безперервної інтеграції повинен бути першим проектом / рішенням. Ви повинні підтримувати свою ієрархію об'єктів, правильно.

Другим рішенням, що має лише один проект (який швидше побудує), буде проект, де тестування та налагодження будуть виконані всіма розробниками. Ви повинні подбати про них, дивлячись на будівельника! Якщо щось порушиться, ОБОВ'ЯЗКОВО виправити.


7

Переконайтеся, що ваші посилання є посиланнями проекту, а не безпосередньо на DLL-файли у вихідних каталогах бібліотеки.

Крім того, у них встановлено, щоб не копіювати локально, за винятком випадків, коли це абсолютно необхідно (головний проект EXE).


Чи можете ви пояснити, чому це швидше? "Посилання на проект" передбачає створення проекту (що набагато повільніше, ніж пряма посилання на DLL).
Пройшов кодування

6

Цю відповідь я опублікував спочатку тут: /programming/8440/visual-studio-optimizations#8473 На цій сторінці можна знайти багато інших корисних підказок.

Якщо ви використовуєте Visual Studio 2008, ви можете компілювати, використовуючи прапор / MP, щоб будувати один проект паралельно. Я читав, що це також недокументована функція у Visual Studio 2005, але ніколи не пробував себе.

Ви можете будувати декілька проектів паралельно, використовуючи прапор / M, але зазвичай це вже встановлено кількість доступних ядер на машині, хоча це стосується лише VC ++, я вважаю.


1
Будь обережний. У 2008 році виникла помилка, яка створює усічки. МС кажуть, що не виправлять до vs2010. Це жахлива проблема, оскільки він обрізає .obj файли, що викликає постійні заплутані проблеми збірки. вас попередили ;) social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/…
Джастін

6

Я помічаю, що це питання давнє вік, але ця тема все ще цікавить сьогодні. Така ж проблема мене зачепила останнім часом, і дві речі, які найбільше покращили ефективність збірки, були (1) використання виділеного (і швидкого) диска для компіляції та (2) використання одного і того ж папки виводу для всіх проектів та встановлення CopyLocal на False для проекту посилання.

Деякі додаткові ресурси:


5

Деякі інструменти аналізу:

інструменти-> параметри-> налаштування проекту VC ++ -> Час побудови = Так, покаже час побудови для кожного vcproj.

Додайте /Btперемикач до командного рядка компілятора, щоб побачити, скільки зайняв кожен файл CPP

Використовуйте /showIncludesдля вилучення вкладених файлів (файли заголовків, які містять інші файли заголовків), і дивіться, які файли можуть врятувати багато IO, використовуючи переадресаційні декларації.

Це допоможе вам оптимізувати продуктивність компілятора, усуваючи залежності та виправлення продуктивності.


5

Перш ніж витрачати гроші на вкладення у швидші жорсткі диски, спробуйте створити проект повністю на диску оперативної пам’яті (якщо припустити, що у вас є запасна оперативна пам’ять). Ви можете знайти різні безкоштовні драйвери оперативної пам’яті в мережі. Ви не знайдете жодного фізичного накопичувача, включаючи SSD, які швидше, ніж диск RAM.

У моєму випадку проект, який потребував 5 хвилин для складання 6-ядерного i7 на 7200 RPM SATA-накопичувачі з Incredibuild, був зменшений лише приблизно на 15 секунд за допомогою диска оперативної пам'яті. Враховуючи необхідність повернення до постійного сховища та потенціал для втраченої роботи, 15 секунд є недостатньо стимулом для використання диска оперативної пам’яті і, ймовірно, не надто стимулу витратити кілька сотень доларів на накопичувач з високим RPM або SSD.

Невеликий приріст може вказувати на те, що збірка була пов'язана з процесором або що кешування файлів Windows було досить ефективним, але оскільки обидва тести були виконані в стані, коли файли не були кешовані, я сильно схиляюся до компіляцій, пов'язаних з процесором.

Залежно від фактичного коду, який ви складаєте, пробіг може змінюватись, тому не соромтесь тестувати.


Диски оперативної пам’яті не допомагають VS створювати моменти в моєму досвіді, і це біль, тому що вам доведеться відтворювати їх щоразу, коли комп'ютер перезавантажується або виходить з ладу. Дивіться тут повідомлення в блозі: josephfluckiger.blogspot.com/2009/02/…
BrokeMyLegBiking

3

Наскільки великий ваш каталог збірок після повного складання? Якщо ви дотримуєтесь налаштувань за замовчуванням, то кожна складена збірка копіюватиме всі DLL-файли своїх залежностей та залежностей залежностей тощо у його каталог бін. У своїй попередній роботі, працюючи над рішенням ~ 40 проектів, мої колеги виявили, що найдорожчою частиною процесу збирання є копіювання цих збірок знову і знову, і що одна збірка може генерувати гігабайти копій одних і тих же DLL і знову, і знову і знову.

Ось декілька корисних порад від Патріка Смакіа, автора NDepend, про те, що він вважає, що повинно бути, а що не повинно бути окремим складанням:

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

В основному є два способи обійти це, і в обох є недоліки. Одне - зменшити кількість збірок, що, очевидно, велика робота. Інша полягає в тому, щоб реструктурувати каталоги збірки, щоб усі ваші папки бін були консолідовані, а проекти не копіювали DLL-файли своїх залежностей - вони не потребують, оскільки вони вже є в одному каталозі. Це різко зменшує кількість файлів, створених та скопійованих під час збирання, але це може бути важко налаштувати, і ви можете з певними труднощами витягнути лише DLL-файли, необхідні певним виконуваним файлом для упаковки.


Я покинув роботу, що це було проблемою на деякий час назад, але на моїй новій посаді це саме те, що ми реалізували! Ура. JC
johnc

2

Можливо, скористайтеся деякими загальними функціями та створіть деякі бібліотеки, таким чином одні і ті ж джерела не збираються знову і знову для декількох проектів.

Якщо ви турбуєтесь про змішування різних версій DLL, використовуйте статичні бібліотеки.


DLL (і її різні родичі люблять спільні бібліотеки) майже завжди є поганою ідеєю для розробника додатків сьогодні. Виконані файли невеликі, навіть якщо ви з'єднуєтеся з кожною останньою бібліотекою, яку ви використовуєте, і об'єм пам'яті, яку ви збережете, поділившись кодом, також невеликий. DLL повертаються до тих часів, коли слід програмного коду в пам'яті та на диску був ключовим, але розмір даних, пам'яті та диска зростав набагато швидше, ніж розмір програм.
Tom Swirly

2

Вимкніть інтеграцію VSS. У вас може не бути вибору для його використання, але DLL постійно "випадково" перейменовані ...

І обов’язково перевірте свої попередньо складені настройки заголовка. Посібник Брюса Доусона трохи старий, але все ще дуже хороший - перевірте це: http://www.cygnus-software.com/papers/precompiledheaders.html


Безумовно, ми можемо вимкнути інтеграцію до VSS і замість цього перейти через Source Safe UI. Приємна думка
johnc

2

У мене є проект, який налічує 120 і більше exes, libs і dll і потребує значного часу на його створення. Я використовую дерево пакетних файлів, які викликають створення файлів з одного головного пакетного файлу. У мене були проблеми з дивними речами з поступових (або це були темпераментні) заголовки в минулому, тому я уникаю їх зараз. Я роблю повний збір нечасто, і зазвичай залишаю його до кінця дня, поки я йду на прогулянку на годину (тому я можу лише здогадуватися, що це займає близько півгодини). Тож я розумію, чому це неможливо для роботи та тестування.

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

Пакетний файл також копіює завершений результат у (або кілька) тестових папок. Залежно від налаштувань, це закінчується за кілька секунд до хвилини (на відміну від півгодини).

Я використовував інший IDE (Zeus), оскільки мені подобається контролювати такі речі, як .rc файли, і насправді вважаю за краще компілювати з командного рядка, хоча я використовую MS-компілятори.

Раді опублікувати приклад цього пакетного файлу, якщо хтось зацікавлений.


2

Вимкнути індексацію файлової системи у своїх джерелах (зокрема, в об'єктних каталогах, якщо ви хочете, щоб ваш джерело можна шукати)



1

Ви також можете перевірити наявність кругових посилань на проект. Колись це було для мене проблемою.

Це є:

Посилання на проект Проект B

Посилання на проект B Проект C

Посилання на проект C Проект A


1
Якби це було так, рішення ніколи не складеться.
Майкл

@Michael буде компілюватися, якщо ви посилаєтеся на dll в каталог налагодження, замість використання посилань на проекти.
Калеб Ярес

1

Однією більш дешевою альтернативою Xoreax IB є використання того, що я називаю, збірки файлів uber. В основному це .cpp-файл, який є

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

Потім ви складаєте одиниці uber замість окремих модулів. Ми бачили час компіляції від 10-15 хвилин до 1-2 хвилин. Можливо, вам доведеться переконатися в тому, скільки #includes на файл uber має сенс. Залежить від проектів. Можливо, ви включаєте 10 файлів, можливо 20.

Ви оплачуєте вартість, тому будьте обережні:

  1. Ви не можете клацнути правою кнопкою миші файл та сказати "компілювати ...", оскільки ви повинні виключити окремі файли cpp із збірки та включати лише файли cpp uber.
  2. Ви повинні бути обережними щодо статичних глобальних конфліктів змінних.
  3. Додаючи нові модулі, ви повинні постійно оновлювати файли uber

Це якась біль, але для проекту, який значною мірою є статичним щодо нових модулів, почуття болю, можливо, варто того. Я бачив, як цей метод перемагав ІБ в деяких випадках.


1

Якщо це проект C ++, то ви повинні використовувати заздалегідь складені заголовки. Це робить велику різницю в часі компіляції. Не впевнений, що насправді робить cl.exe (не використовуючи попередньо складені заголовки), схоже, шукає безліч заголовків STL у всіх неправильних місцях, перш ніж нарешті перейти в потрібне місце. Це додає цілі секунди до кожного компільованого .cpp-файлу. Не впевнений, це помилка cl.exe чи якась проблема STL у VS2008.


1

Дивлячись на машину, на якій ви будуєте, вона оптимально налаштована?

Ми щойно заробили час для створення нашого найбільшого C -+ продуктового масштабу з 19 годин до 16 хвилин , забезпечивши встановлення потрібного драйвера фільтра SATA.

Тонкі.


Швидкість руху приводу, безумовно, є фактором, що сприяє
жовтня

Не налаштовано оптимально. 2 Гб оперативної пам’яті - це занадто мало для початку.
TomTom

1

У Visual Studio 2005 є незадокументований / перемикач MP, див. Http://lahsiv.net/blog/?p=40 , який би дозволив паралельну компіляцію на файльній основі, а не на проектній основі. Це може прискорити складання останнього проекту або, якщо ви складете один проект.


1

Вибираючи процесор: розмір кешу L1, здається, має величезний вплив на час компіляції. Крім того, зазвичай краще мати 2 швидких ядра, ніж 4 повільних. Visual Studio не використовує зайві ядра дуже ефективно. (Я базую це на своєму досвіді компілятора C ++, але, мабуть, це стосується і C # one.)


1

Я також зараз переконаний, що існує проблема з VS2008. Я запускаю його на двоядерному ноутбуці Intel з 3G Ram, з вимкненим антивірусом. Компіляція рішення часто є досить гладкою, але якщо я налагоджував наступну перекомпіляцію, часто сповільнюється до сканування. З постійного світла основного диска зрозуміло, що є вузьке місце вводу / виводу диска (ви також можете його почути). Якщо я скасую VS збірки та відключення, активність диска припиняється. Перезапустіть VS, перезавантажте рішення, а потім відновіть, і це набагато швидше. У наступний раз

Думаю, що це проблема підкачки пам’яті - у VS просто не вистачає пам’яті, і O / S починає міняти сторінку, щоб спробувати зайняти місце, але VS вимагає більше, ніж може зробити заміна сторінки, тому вона сповільнюється до сканування. Я не можу придумати жодного іншого пояснення.

VS точно не є інструментом RAD, чи не так?


У мене також була проблема з VS2005 - безумовно,
підказка

1

Чи трапляється, якщо ваша компанія випадково використовує Entrust для рішення PKI / Encryption? Виявляється, у нас були аномальні показники збірки для досить великого веб-сайту, побудованого на C #, зайнявши 7+ хвилин на Rebuild-All.

Моя машина i7-3770 з 16 Гб оперативної пам’яті та 512 Гб SSD, тому продуктивність не повинна була бути такою поганою. Я помітив, що мої часи збірки були шалено швидшими на старшій машині, що будує ту саму кодову базу. Тож я запустив ProcMon на обох машинах, профілював складання та порівняв результати.

Ось, ось повільнодіюча машина мала одну різницю - посилання на Entrust.dll в стек-трасі. Використовуючи цю нещодавно придбану інформацію, я продовжував шукати StackOverflow і виявив це: MSBUILD (VS2010) дуже повільно працює на деяких машинах . Відповідно до прийнятої відповіді, проблема полягає в тому, що обробник Entrust обробляв чеки сертифікатів .NET замість власного обробника Microsoft. Tt також припускає, що Entrust v10 вирішує цю проблему, яка є поширеною в Entrust 9.

У мене зараз його не видалено, і час моїх збірок зменшився до 24 секунд . YYMV з кількістю проектів, які ви зараз будуєте, і, можливо, безпосередньо не вирішує питання масштабування, про який ви питали. Я опублікую редагування цієї відповіді, якщо зможу надати виправлення, не вдаючись до видалення програмного забезпечення.


0

Це певна проблема з VS2008. Тому що єдине, що я зробив, це встановити VS2008 для оновлення мого проекту, створеного з VS2005. У моєму вирішенні лише 2 проекти. Він не великий. Компіляція з VS2005: 30 секунд Компіляція з VS2008: 5 хвилин


Там має бути ще одне питання, два проекти повинні працювати добре на гідній машині
johnc

0

Приємні пропозиції, які допомогли досі (не кажучи, що немає інших приємних пропозицій нижче, якщо у вас є проблеми, я рекомендую прочитати тоді, лише те, що допомогло нам)

  • Новий ноутбук 3 ГГц - потужність втраченої утилізації творить чудеса під час бігу до управління
  • Вимкнути антивірус під час компіляції
  • 'Відключення' від VSS (власне мережі) під час компіляції - я можу змусити нас повністю видалити інтеграцію VS-VSS і дотримуватися використання інтерфейсу VSS

Все ще не зривати хропіння через компіляцію, але кожен біт допомагає.

Ми також тестуємо практику побудови нових областей програми в нових рішеннях, імпортуємо в новітні місця, якщо потрібно, інтегруючи їх у більш широке рішення, коли ми з ними задоволені.

Ми також можемо виконати їх із існуючим кодом, створивши тимчасові рішення, які просто інкапсулюють сфери, над якими нам потрібно працювати, і викинувши їх після реінтеграції коду. Нам потрібно зважити час, який знадобиться для реінтеграції цього коду до часу, який ми отримуємо, не маючи Rip Van Winkle, як досвід швидкого перекомпіляції під час розробки.

Оріон згадував у коментарі, що генерики також можуть мати гру. З моїх тестів, схоже, є мінімальна ефективність, але недостатньо висока, щоб впевнитись - час компіляції може бути невідповідним через активність диска. Через обмеження в часі мої тести не включали стільки дженериків чи стільки коду, скільки було б у живій системі, щоб вони могли накопичуватися. Я б не уникав використання дженериків там, де вони повинні використовуватися, лише для часу компіляції

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.