«Да сколько ты ещё будешь собирать?» — фраза, которую каждый разработчик произносил хотя бы раз посреди ночи. Да, сборка бывает долгой и от этого никуда не деться. Нельзя же просто так взять и распараллелить всё это дело не на каких-то жалких 8 – 12 ядер, а так, чтобы на 100+. Или всё-таки можно?
Мне нужно больше ядер!
Как вы могли заметить, речь сегодня пойдёт как раз о том, как можно ускорить компиляцию. И нет, в этот раз будут рассмотрены не какие-то специфичные механизмы, а самое обычное распараллеливание. Ну, тут всё, казалось бы, просто – выставляем доступное физически количество ядер, нажимаем на build и идём пить условный чай.
Но с ростом кодовой базы время компиляции постепенно растёт и однажды оно станет настолько большим, что полностью проект будет собираться разве что ночью. Поэтому нужно подумать о том, как бы всё это ускорить. Вокруг же сидят довольные коллеги, которые занимаются своими программистскими делами, а их машины тихо и не напрягаясь выводят немного текста на экраны.
IncrediBuild
«Взять бы у этих бездельников ядра» — могли вы подумать. И правильно бы сделали, ведь это вполне себе можно реализовать. Но не нужно, конечно, принимать мои слова близко к сердцу и вооружаться паяльником. Впрочем, это уже на ваше усмотрение 🙂
Отдай!
Так как реквизировать машины коллег нам вряд ли кто-либо даст, будем пользоваться обходными путями. Даже если у вас и получилось убедить своих коллег поделиться железом, всё равно пользы от лишних процессоров у вас не будет, разве что можете выбрать себе тот, который пошустрее. А нам нужно то решение, которое каким-то образом позволит запускать дополнительные потоки сборки на удалённых машинах.
Благо среди тысяч категорий всякого полезного ПО, затесалась и нужная нам — система распределённой сборки. Программы этой категории делают именно то, что нам было и нужно: выдают на время простаивающие ядра коллег и при этом делают это без их ведома в автоматическом режиме. Разве что сперва нужно будет поставить всё это на их машины, но об этом немного позже.
На ком будем проверять?
Для того, чтобы убедиться, что всё функционирует действительно хорошо, нужно было найти качественного подопытного. Так как у нас уже не раз были в статьях и Chromium и Linux, а выделиться как-то хотелось, нужно было найти что-нибудь новое. Поэтому я пошёл в сторону открытых игр (а где же ещё искать большие проекты?). И как вы увидите ниже, очень пожалел об этом решении.
Впрочем, поиск чего-то объёмного труда не составил, да и мне «повезло» повстречать открытый проект на Unreal Engine. Вдуматься только! Я действительно до момента написания этой статьи и подумать не мог, что на UE бывает Open Source.
Итак, герой этой статьи: Unreal Tournament. Только вы не спешите сразу переходить по ссылке, так как вам может понадобиться пара дополнительных кликов — подробности *тут*.
Watch Incredibuild in Action
Да будет сборка на 100+ ядер!
В качестве примера системы распределённой сборки я, пожалуй, остановлюсь на IncrediBuild. Не то, чтобы у меня был большой выбор — у нас была уже лицензия IncrediBuild на 20 машин. Нет, есть, конечно, открытый distcc, но он не так прост в настройке, да и к тому же практически все машины у нас под Windows.
Итак, первым делом нужно поставить агентов на машины других разработчиков. Есть два способа:
- попросить коллег в местном Slack;
- воззвать к силам сисадмина.
Разумеется, как и любой другой наивный человек, я написал сперва в Slack. Спустя пару дней еле-еле дошло до 12 машин из 20. После этого я воззвал к силам сисадмина и, о чудо, заветная двадцатка была у меня в руке. Так что теперь у меня было около 145 ядер (+/- 10) 🙂
За исключением необходимости поставить агентов (делается это парой кликов в установщике), нужно было поставить себе координатора. Это делается немного сложнее, поэтому оставлю ссылку на доки.
Итак, у нас теперь есть сетка на стероидах, поэтому пришло время добраться до Visual Studio. Выбираем в плагине сборку. А вот и нет 🙂
Если вдруг вы и сами захотите попробовать, то учтите, что сперва нужно собрать проекты ShaderCompileWorker и UnrealLightmass. Так как они не большие, я собрал их локально. Вот теперь уже можно нажать на заветную кнопку:
Итак, какая же получилась разница?
Как видите, нам удалось ускорить сборку с 30 минут до почти 6! Очень даже нехило. Кстати, запуск проводился посреди рабочего дня, так что примерно таких цифр можно ожидать и не на синтетическом тесте. Впрочем, от проекта к проекту разница может быть разной.
Что ещё можно ускорить?
Помимо сборки можно натравить IncrediBuild на любую тулзу, которая плодит много подпроцессов. Как вы, может, обратили внимание, я работаю в PVS-Studio. Поэтому конечно же я не могу обойти стороной возможность скормить ему и наш анализатор.
Профит в быстром анализе примерно такой же, как и в быстрой сборке: возможность локальных прогонов перед коммитом. Конечно, всегда есть желание залить всё сразу в мастер; но обычно тимлид бывает не в восторге от подобных действий, особенно когда валятся ночные прогоны на сервере. Поверьте мне – я валил 🙁
Настраивать особенно анализатор не нужно, разве что нам не повредит указать старые-добрые 145 потоков в настройках:
Ну и стоит указать местной сборочной системе кто тут анализатор:
Итак, пришло время нажать на сборку ещё раз и насладиться ускорением:
Вышло около семи минут, что подозрительно похоже на время сборки. Тут я и подумал, что видимо забыл добавить флаг. Зашёл в настройки и увидел, что всё на месте. Такого я не ожидал, поэтому отправился курить мануалы.
Попытка запуска PVS-Studio #2
Спустя какое-то время я вспомнил про версию Unreal Engine, которая используется в этом проекте:
Не то, чтобы это плохо само по себе, но флаг -StaticAnalyzer появился много позже. Поэтому интегрироваться напрямую не то, чтобы было возможно. Примерно на этом моменте я уже начал задумываться о том, чтобы забить на всё это дело и уйти пить кофе.
После пары кружек бодрящего напитка у меня возникла мысль всё-таки дочитать туториал по интеграции до конца. Помимо указанного выше способа есть ещё и мониторинг компиляции. Это как раз тот вариант, когда ничего уже не помогает.
Первым делом включим сервер мониторинга:
CLMonitor.exe monitor
Эта штука будет крутиться на фоне и следить за тобой вызовами компилятора. Но она не может отслеживать происходящее в IncrediBuild, поэтому придётся один раз собрать без него.
На фоне предыдущего запуска локальная пересборка выглядит очень бедно:
Total build time: 1710,84 seconds (Local executor: 1526,25 seconds)
Теперь сохраним то, что насобирали в отдельный файл:
CLMonitor.exe saveDump -d dump.gz
Дальше можно будет пользоваться этим дампом, пока вы не добавите новый файл в проект. Да, это не так удобно, как с флагом, но ничего не поделаешь – версия движка слишком старая.
Сам же анализ запускается вот этой командой:
CLMonitor.exe analyzeFromDump -l UE.plog -d dump.gz
Только не стоит его так запускать, ведь мы же хотим его запустить под IncrediBuild. Так что закинем эту команду в analyze.bat. И создадим рядом файл profile.xml:
И теперь мы можем запустить всё с нашими 145-ю ядрами:
ibconsole /command=analyze.bat /profile=profile.xml
И как это выглядит в Build Monitor:
К нам закралась ещё одна проблема. И в этот раз дело не в то, что кто-то что-то не поддерживает. Сборка Unreal Tournament оказалась несколько специфичной.
Попытка запуска PVS-Studio #3
Если посмотреть внимательно, то это не ошибки анализа, а неудачи при препроцессировании исходников. Причём, причина данного фейла была одна и та же:
. Build.h(42): fatal error C1189: #error: Exactly one of [UE_BUILD_DEBUG UE_BUILD_DEVELOPMENT UE_BUILD_TEST UE_BUILD_SHIPPING] should be defined to be 1
Так в чём проблема? Всё довольно просто – препроцессор требует, чтобы только один из следующих макросов имел значение 1:
- UE_BUILD_DEBUG;
- UE_BUILD_DEVELOPMENT;
- UE_BUILD_TEST;
- UE_BUILD_SHIPPING.
Да, вроде как всё собиралось раньше, а теперь что-то страшное вылетело. Пришлось закопаться в логи, а точнее в дамп компиляции. Там-то проблема и нашлась. Дело было в том, что эти макросы объявляются в местном precompile header, а мы хотим только препроцессировать. Так что пришлось добавить все эти макросы вручную:
#ifdef PVS_STUDIO #define _DEBUG #define UE_BUILD_DEVELOPMENT 1 #define WITH_EDITOR 1 #define WITH_ENGINE 1 #define WITH_UNREAL_DEVELOPER_TOOLS 1 #define WITH_PLUGIN_SUPPORT 1 #define UE_BUILD_MINIMAL 1 #define IS_MONOLITHIC 1 #define IS_PROGRAM 1 #define PLATFORM_WINDOWS 1 #endif
Самое начало файла build.h
И уже с этим небольшим костылём элегантным решением можно запустить анализ. Причём сборка не сломается, так как мы воспользовались макросом PVS_STUDIO.
Итак, долгожданные результаты анализа:
Согласитесь, почти 15 минут вместо двух с половиной часов – это очень хорошее ускорение. Сложно представить, чтобы вы могли пить кофе 2 часа к ряду и ни у кого не возникло бы сомнений на ваш счёт. А вот 15 минутный перекур вопросов не вызывает. Наверно.
И что у нас в итоге?
Разумеется, что в идеальном мире увеличение количества потоков в N раз увеличило бы скорость сборки в N раз. Но живём мы в совершенно ином мире, поэтому стоит учитывать локальную нагрузку на агентов (удалённые машины), нагрузку на сеть, время на организацию всего этого дела и ещё много деталей, которые скрыты под капотом.
Впрочем, ускорение действительно есть и местами оно позволяет не просто запускать полную сборку или же анализ раз в день, а делать это куда чаще. Например, после каждого фикса или же перед коммитами. А теперь предлагаю посмотреть на то, как это всё выглядит в одной таблице:
Источник: habr.com
Ускоряем сборку и анализ при помощи Incredibuild
«Да сколько ты ещё будешь собирать?» – фраза, которую каждый разработчик произносил хотя бы раз посреди ночи. Да, сборка бывает долгой и от этого никуда не деться. Нельзя же просто так взять и распараллелить всё это дело не на каких-то жалких 8–12 ядер, а так, чтобы на 100+. Или всё-таки можно?
Мне нужно больше ядер!
Как вы могли заметить, речь сегодня пойдёт как раз о том, как можно ускорить компиляцию. И нет, в этот раз будут рассмотрены не какие-то специфичные механизмы, а самое обычное распараллеливание. Ну, тут всё, казалось бы, просто – выставляем доступное физически количество ядер, нажимаем на build и идём пить условный чай.
Но с ростом кодовой базы время компиляции постепенно растёт и однажды оно станет настолько большим, что полностью проект будет собираться разве что ночью. Поэтому нужно подумать о том, как бы всё это ускорить. Вокруг же сидят довольные коллеги, которые занимаются своими программистскими делами, а их машины тихо и не напрягаясь выводят немного текста на экраны.
«Взять бы у этих бездельников ядра», – могли вы подумать. И правильно бы сделали, ведь это вполне себе можно реализовать. Но не нужно, конечно, принимать мои слова близко к сердцу и вооружаться паяльником. Впрочем, это уже на ваше усмотрение 🙂
Отдай!
Так как реквизировать машины коллег нам вряд ли кто-либо даст, будем пользоваться обходными путями. Даже если у вас и получилось убедить своих коллег поделиться железом, всё равно пользы от лишних процессоров у вас не будет, разве что можете выбрать себе тот, который пошустрее. А нам нужно то решение, которое каким-то образом позволит запускать дополнительные потоки сборки на удалённых машинах.
Благо среди тысяч категорий всякого полезного ПО, затесалась и нужная нам – система распределённой сборки. Программы этой категории делают именно то, что нам было и нужно: выдают на время простаивающие ядра коллег и при этом делают это без их ведома в автоматическом режиме. Разве что сперва нужно будет поставить всё это на их машины, но об этом немного позже.
На ком будем проверять?
Для того чтобы убедиться, что всё функционирует действительно хорошо, нужно было найти качественного подопытного. Так как у нас уже не раз были в статьях и Chromium, и Linux, а выделиться как-то хотелось, нужно было найти что-нибудь новое. Поэтому я пошёл в сторону открытых игр (а где же ещё искать большие проекты?). И, как вы увидите ниже, очень пожалел об этом решении.
Впрочем, поиск чего-то объёмного труда не составил, да и мне «повезло» повстречать открытый проект на Unreal Engine. Вдуматься только! Я действительно до момента написания этой статьи и подумать не мог, что на UE бывает Open Source™.
Итак, герой этой статьи: Unreal Tournament. Подробности *тут*.
Да будет сборка на 100+ ядер!
В качестве примера системы распределённой сборки я, пожалуй, остановлюсь на Incredibuild. Не то чтобы у меня был большой выбор – у нас была уже лицензия Incredibuild на 20 машин. Нет, есть, конечно, открытый distcc, но он не так прост в настройке, да и к тому же практически все машины у нас под Windows.
Итак, первым делом нужно поставить агентов на машины других разработчиков. Есть два способа:
- попросить коллег в местном Slack;
- воззвать к силам сисадмина.
Разумеется, как и любой другой наивный человек, я написал сперва в Slack. Спустя пару дней еле-еле дошло до 12 машин из 20. После этого я воззвал к силам сисадмина, и, о чудо, заветная двадцатка была у меня в руке. Так что теперь у меня было около 145 ядер (+/- 10) 🙂
За исключением необходимости поставить агентов (делается это парой кликов в установщике), нужно было поставить себе координатора. Это делается немного сложнее, поэтому оставлю ссылку на доки.
Итак, у нас теперь есть сетка на стероидах, поэтому пришло время добраться до Visual Studio. Выбираем в плагине сборку. А вот и нет 🙂
Если вдруг вы и сами захотите попробовать, то учтите, что сперва нужно собрать проекты ShaderCompileWorker и UnrealLightmass. Так как они небольшие, я собрал их локально. Вот теперь уже можно нажать на заветную кнопку:
Итак, какая же получилась разница?
Как видите, нам удалось ускорить сборку с 30 минут до почти 6! Очень даже нехило. Кстати, запуск проводился посреди рабочего дня, так что примерно таких цифр можно ожидать и не на синтетическом тесте. Впрочем, от проекта к проекту разница может быть разной.
Что ещё можно ускорить?
Помимо сборки можно натравить Incredibuild на любую тулзу, которая плодит много подпроцессов. Как вы, может, обратили внимание, я работаю в PVS-Studio. Поэтому, конечно же, я не могу обойти стороной возможность скормить ему и наш анализатор.
Профит в быстром анализе примерно такой же, как и в быстрой сборке: возможность локальных прогонов перед коммитом. Конечно, всегда есть желание залить всё сразу в мастер; но обычно тимлид бывает не в восторге от подобных действий, особенно когда валятся ночные прогоны на сервере. Поверьте мне – я валил 🙁
Настраивать особенно анализатор не нужно, разве что нам не повредит указать старые-добрые 145 потоков в настройках:
Ну и стоит указать местной сборочной системе, кто тут анализатор:
Итак, пришло время нажать на сборку ещё раз и насладиться ускорением:
Вышло около семи минут, что подозрительно похоже на время сборки. Тут я и подумал, что видимо забыл добавить флаг. Зашёл в настройки и увидел, что всё на месте. Такого я не ожидал, поэтому отправился курить мануалы.
Попытка запуска PVS-Studio #2
Спустя какое-то время я вспомнил про версию Unreal Engine, которая используется в этом проекте:
Не то чтобы это плохо само по себе, но флаг -StaticAnalyzer появился много позже. Поэтому интегрироваться напрямую не то чтобы было возможно. Примерно на этом моменте я уже начал задумываться о том, чтобы забить на всё это дело и уйти пить кофе.
После пары кружек бодрящего напитка у меня возникла мысль всё-таки дочитать туториал по интеграции до конца. Помимо указанного выше способа есть ещё и мониторинг компиляции. Это как раз тот вариант, когда ничего уже не помогает.
Первым делом включим сервер мониторинга:
CLMonitor.exe monitor
Эта штука будет крутиться на фоне и следить за тобой вызовами компилятора. Но она не может отслеживать происходящее в Incredibuild, поэтому придётся один раз собрать без него.
На фоне предыдущего запуска локальная пересборка выглядит очень бедно:
Total build time: 1710,84 seconds (Local executor: 1526,25 seconds)
Теперь сохраним то, что насобирали в отдельный файл:
CLMonitor.exe saveDump -d dump.gz
Дальше можно будет пользоваться этим дампом, пока вы не добавите новый файл в проект. Да, это не так удобно, как с флагом, но ничего не поделаешь – версия движка слишком старая.
Сам же анализ запускается вот этой командой:
CLMonitor.exe analyzeFromDump -l UE.plog -d dump.gz
Только не стоит его так запускать, ведь мы же хотим его запустить под Incredibuild. Так что закинем эту команду в analyze.bat. И создадим рядом файл profile.xml:
И теперь мы можем запустить всё с нашими 145 ядрами:
ibconsole /command=analyze.bat /profile=profile.xml
И как это выглядит в Build Monitor:
К нам закралась ещё одна проблема. И в этот раз дело не в том, что кто-то что-то не поддерживает. Сборка Unreal Tournament оказалась несколько специфичной.
Попытка запуска PVS-Studio #3
Если посмотреть внимательно, то это не ошибки анализа, а неудачи при препроцессировании исходников. Причём, причина данного фейла была одна и та же:
. Build.h(42): fatal error C1189: #error: Exactly one of [UE_BUILD_DEBUG UE_BUILD_DEVELOPMENT UE_BUILD_TEST UE_BUILD_SHIPPING] should be defined to be 1
Так в чём проблема? Всё довольно просто – препроцессор требует, чтобы только один из следующих макросов имел значение 1:
- UE_BUILD_DEBUG;
- UE_BUILD_DEVELOPMENT;
- UE_BUILD_TEST;
- UE_BUILD_SHIPPING.
Да, вроде как всё собиралось раньше, а теперь что-то страшное вылетело. Пришлось закопаться в логи, а точнее – в дамп компиляции. Там-то проблема и нашлась. Дело было в том, что эти макросы объявляются в местном precompile header, а мы хотим только препроцессировать. Так что пришлось добавить все эти макросы вручную:
#ifdef PVS_STUDIO #define _DEBUG #define UE_BUILD_DEVELOPMENT 1 #define WITH_EDITOR 1 #define WITH_ENGINE 1 #define WITH_UNREAL_DEVELOPER_TOOLS 1 #define WITH_PLUGIN_SUPPORT 1 #define UE_BUILD_MINIMAL 1 #define IS_MONOLITHIC 1 #define IS_PROGRAM 1 #define PLATFORM_WINDOWS 1 #endif
Самое начало файла build.h
И уже с этим небольшим костылём элегантным решением можно запустить анализ. Причём сборка не сломается, так как мы воспользовались макросом PVS_STUDIO.
Итак, долгожданные результаты анализа:
Согласитесь, почти 15 минут вместо двух с половиной часов – это очень хорошее ускорение. Сложно представить, чтобы вы могли пить кофе 2 часа кряду и ни у кого не возникло бы сомнений на ваш счёт. А вот 15-минутный перекур вопросов не вызывает. Наверное.
И что у нас в итоге?
Разумеется, что в идеальном мире увеличение количества потоков в N раз увеличило бы скорость сборки в N раз. Но живём мы в совершенно ином мире, поэтому стоит учитывать локальную нагрузку на агентов (удалённые машины), нагрузку на сеть, время на организацию всего этого дела и ещё много деталей, которые скрыты под капотом.
Впрочем, ускорение действительно есть, и местами оно позволяет не просто запускать полную сборку или же анализ раз в день, а делать это куда чаще. Например, после каждого фикса или же перед коммитами. А теперь предлагаю посмотреть на то, как это всё выглядит в одной таблице:
Я запустил по пять раз и посчитал среднее по запускам (эти цифры вы и видели в графиках) 🙂
Источник: pvs-studio.ru
Как ускорить сборку и анализ вашего проекта с помощью IncrediBuild?
— Сколько еще ты собираешься его строить? — фраза, которую хотя бы раз посреди ночи произносил каждый разработчик. Да, сборка может быть долгой, и от нее никуда не деться. Нельзя просто так все это дело перераспределить между 100+ ядрами, вместо каких-то жалких 8-12. Или это возможно?
Мне нужно больше ядер!
Как вы могли заметить, сегодняшняя статья посвящена тому, как ускорить компиляцию и статический анализ. Но какое отношение ускорение компиляции имеет к статическому анализу? Все просто — то, что ускоряет компиляцию, ускоряет и анализ. И нет, в этот раз мы не будем говорить о каких-то конкретных решениях, а вместо этого сосредоточимся на самом распространенном распараллеливании. Ну тут вроде бы все просто — указываем физически доступное количество процессорных ядер, нажимаем команду сборки и идем пить пресловутый чай.
Но с ростом кодовой базы время компиляции постепенно увеличивается. Поэтому однажды он станет настолько большим, что только ночное время останется пригодным для строительства целого проекта. Поэтому надо думать, как все это ускорить. А теперь представьте — вы сидите в окружении довольных коллег, занятых своими мелкими программными делами. Их машины отображают какой-то текст на своих экранах, тихо, без какой-либо нагрузки на их оборудование…
«Хотел бы я взять ядра у этих бездельников…» — подумаете вы. Это было бы правильно, так как это довольно легко. Пожалуйста, не принимайте мои слова близко к сердцу, вооружившись бейсбольной битой! Впрочем, это на ваше усмотрение 🙂
Дай это мне!
Поскольку маловероятно, что кто-то позволит нам реквизировать машины наших коллег, вам придется искать обходные пути. Даже если вам удалось убедить коллег поделиться оборудованием, вы все равно не получите дополнительных процессоров, разве что сможете выбрать тот, который быстрее. Что касается нас, то нам нужно решение, которое каким-то образом позволит запускать дополнительные процессы на удаленных машинах.
К счастью, среди тысяч категорий софта втиснулась и нужная нам распределенная система сборки. Такие программы делают именно то, что нам нужно: они могут доставлять нам простаивающие ядра наших коллег и, в то же время, делать это. без их ведома в автоматическом режиме. Правда, сначала нужно все это установить на свои машины, но об этом позже…
На ком будем тестировать?
Чтобы убедиться, что все работает действительно хорошо, мне пришлось найти качественный испытуемый. Поэтому я прибегнул к играм с открытым исходным кодом. Где еще я могу найти большие проекты? И как вы увидите ниже, я очень пожалел об этом решении.
Однако я легко нашел крупный проект. Мне посчастливилось наткнуться на проект с открытым исходным кодом на Unreal Engine. К счастью, IncrediBuild отлично справляется с распараллеливанием проектов в UnrealBuildSystem.
Итак, встречайте главного героя этой статьи: Нереальный Турнир. Но не нужно торопиться и сразу переходить по ссылке. Возможно, вам понадобится пара дополнительных кликов, подробности смотрите *здесь*.
Да начнется сборка более 100 ядер!
В качестве примера распределенной системы сборки я выберу IncrediBuild. Не то чтобы у меня был большой выбор — у нас уже есть лицензия IncrediBuild на 20 машин. Есть еще open source distcc, но его не так просто настроить. Кроме того, почти все наши машины на Windows.
Итак, первый шаг — установка агентов на машины других разработчиков. Есть два способа:
- спросите своих коллег через местный Slack;
- обращение к полномочиям системного администратора.
Конечно, как и любой другой наивный человек, я сначала задал вопрос в Slack… Через пару дней он едва дошел до 12 машин из 20. После этого я воззвал к силе сисадмина. И вот! Получил заветную двадцатку! Итак, на тот момент у меня было около 145 ядер (+/- 10) 🙂
Что мне нужно было сделать, так это установить агентов (парой кликов в установщике) и координатора. Это немного сложнее, поэтому оставлю ссылку на документы.
Итак, теперь у нас есть распределенная сеть сборки на стероидах, поэтому пора переходить к Visual Studio. Уже добрались до команды сборки?… Не так быстро 🙂
Если вы хотите попробовать весь процесс самостоятельно, имейте в виду, что сначала вам нужно собрать проекты ShaderCompileWorker и UnrealLightmass. Так как они не большие, я построил их на месте. Теперь можно нажать на заветную кнопку:
Итак, в чем разница?
Как видите, нам удалось ускорить сборку с 30 минут до почти 6! Действительно не плохо! Кстати, сборку мы запускали в середине рабочего дня, так что можно ожидать таких цифр и на реальном тесте. Однако разница может варьироваться от проекта к проекту.
Что еще будем ускорять?
В дополнение к сборке IncrediBuild можно скармливать любому инструменту, производящему множество подпроцессов. Сам работаю в PVS-Studio. Мы разрабатываем статический анализатор под названием PVS-Studio. Да, думаю, вы уже догадались 🙂 Передадим в IncrediBuild для распараллеливания.
Быстрый анализ так же гибок, как и быстрая сборка: мы можем получить локальные прогоны перед фиксацией. Всегда хочется загрузить все файлы сразу на мастер. Однако ваш тимлид может быть не в восторге от таких действий, особенно когда на сервере вылетают ночные сборки… Поверьте мне — я через это прошел 🙁
Анализатору особых настроек не потребуется, разве что в настройках можно указать старые добрые 145 потоков анализа:
Что ж, стоит показать локальной системе сборки, кто тут большой анализатор:
Итак, пришло время снова нажать на сборку и насладиться приростом скорости:
На это ушло около семи минут, что подозрительно похоже на время сборки… Тут я подумал, что, наверное, забыл поставить флаг. А вот на экране настроек ничего не пропало… Не ожидал, поэтому пошел изучать мануалы.
Попытка запустить PVS-Studio #2
Через какое-то время я вспомнил версию Unreal Engine, использовавшуюся в этом проекте:
Не то, чтобы это само по себе было плохо, но поддержка флага -StaticAnalyzer появилась гораздо позже. Поэтому интегрировать анализатор напрямую не совсем возможно. Примерно в этот момент я начал думать о том, чтобы бросить все это и выпить кофе.
После пары чашек освежающего напитка мне пришла в голову мысль дочитать учебник по интеграции анализатора до конца. В дополнение к вышеуказанному методу существует также метод мониторинг компиляции. Это вариант для тех случаев, когда уже ничего не помогает.
Прежде всего, мы включим сервер мониторинга:
CLMonitor.exe monitor
Эта штука будет работать в фоновом режиме, наблюдая за вызовами компилятора. Это даст анализатору всю необходимую информацию для проведения самого анализа. Но отследить, что происходит в IncrediBuild, он не может (потому что IncrediBuild распределяет процессы по разным машинам, а мониторинг работает только локально), так что придется один раз собирать без него.
Локальная пересборка выглядит очень медленно по сравнению с предыдущим запуском:
Total build time: 1710,84 seconds (Local executor: 1526,25 seconds)
Теперь сохраним собранное в отдельный файл:
CLMonitor.exe saveDump -d dump.gz