Для VS2010 (C ++), что вызывает большую задержку между нажатием на «Build» и началом фактической сборки? - PullRequest
2 голосов
/ 02 декабря 2011

У меня есть простое решение для одного проекта на C ++.В IDE я нажимаю на Build Solution, и до того, как что-то случится, уходит 40 секунд.Затем 17 секунд, чтобы фактически сделать компиляцию и компоновку.Если я снова нажму «Построить решение», будет еще 40-секундная задержка.devenv.exe занят, делая что-то , так как он использует 13% моего общего процессора в течение этого времени.

Если я вызываю msbuild напрямую, он запускается немедленно.И он не перекомпилируется, если он действительно не устарел.Так что, похоже, это не проблема с msbuild.

Я прогуглил и прогнал много статей, но большинство из них говорят о том, почему msbuild работает медленно или не работает, а не почему IDE работает медленно.позвонить в msbuild.У меня даже есть настройка внешнего инструмента с использованием msbuild, и она запускается немедленно.Кстати, этот инструмент основан на этом:

http://www.hanselman.com/blog/HackParallelMSBuildsFromWithinTheVisualStudioIDE.aspx

Я проверил наличие недостающих файлов с помощью изменения devenv.exe.config, и я do получаю такие элементы, как:

devenv.exe Information: 0 :     
Project 'C:\Users\...\XFPMon\XFPMon.vcxproj' not up to date because 2 build outputs were missing.   
devenv.exe Information: 0 :     
up to date is missing: 'C:\WINDOWS\TEMP\AEXAM\AEX7C29.TMP'  
devenv.exe Information: 0 :     
up to date is missing: 'C:\WINDOWS\TEMP\AEXAM\AEX7C28.TMP'  

В файл devenv.exe.config было внесено изменение:

<system.diagnostics>
    <switches>
        <add name="CPS" value="4" />
    </switches>
</system.diagnostics>

и затем использование DbgView для отслеживания вывода во время сборки.Я не могу себе представить, почему devenv.exe считает, что файлы TEMP будут сохраняться между сборками.

Я даже удалил каталоги Debug и Release и скомпилировал его с нуля.Все равно задержка 40 секунд.

Если я сделаю решение по перестройке, еще 40 секунд задержки.

Но если я сделаю чистое решение, оно запустится мгновенно!

Кто-нибудь сделает?Понять, что вызывает задержку?

Спасибо!

РЕДАКТИРОВАТЬ: Дополнительная информация.У меня 8 ядер, 12 ГБ оперативной памяти и 256 ГБ твердотельный накопитель, так что у этой маленькой машины есть достаточно мощности.

Когда devenv.exe находится в 40-секундном периоде задержки, он потребляет в общей сложности 13% ЦП.Когда начинается компиляция, она падает до менее 1%.Использование памяти меняется очень мало.Он начинается с 458,2 МБ, увеличивается до 459,9 МБ в течение 40-секундной задержки, а затем сразу после завершения компиляции (если есть) переходит к 463,1 МБ.

1 Ответ

2 голосов
/ 09 декабря 2011

Ну, я нашел проблему.Надстройка затрачивала экспоненциальное время на обработку файлов .rc и .rc2.Аддин был установлен много месяцев назад и не начал показывать эту проблему, пока размер файла .rc не вырос настолько, чтобы заставить (плохо спроектированное) регулярное выражение работать очень медленно.

Хуже того, я написал аддин!И пользуюсь им на нескольких машинах около года без проблем.Предыдущие версии Addin были написаны на C ++ с использованием регулярных выражений PCRE и никогда не имели проблем (даже после 5 лет использования).Но это было переписано с использованием C # и .NET Regex, которые, по-видимому, ведут себя по-разному.

Я исправил проблему, переписав код, чтобы избежать необходимости некоторого возврата.Достаточно просто сделать, но раздражает, что это было необходимо для C # Regex.

Ключом к обнаружению проблемы было запустить devenv.exe с параметром / resetaddin.При этом сборка начинается немедленно.Тогда нужно было просто выяснить, какое дополнение.Я просто не делал этого, так как не менял надстройки в течение нескольких месяцев.

Эта проблема обнаружилась, когда размер файла .rc был всего 12K.Я протестировал новую версию на 262K файле .rc, и она работает за 123 мс.

Sigh.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...