Visual studio компилятору не хватает размера кучи

Обновлено: 04.07.2024

Visual C++ Compilers (targeting x86, X64 and ARM)
Visual C++ headers & libraries (CRT & STL)
Visual C++ build scripts (targeting Windows desktop)
Microsoft Build Tools 2015 (MSBuild)
Windows SDK 8.1 (optional, on by default)
Windows SDK 10 (optional, off by default)
C++ Build tools specific command prompts
MFC and ATL (added with VS 2015 Update 3)

Таким образом, Enterprise WDK содержит все необходимое для сборки драйверов и базовых тестовых Win32-приложений. Установка продукта крайне проста --- в соответствии с заявленными целями он поставляется в виде единственного zip-файла "весом" около 1,8 Гб, который надо просто распаковать и запустить скрипт настройки от имени администратора. Распакованный архив занимает уже около 5,7 Гб.

Подчеркнем еще раз, что эти продукты имеют интерфейс командной строки --- никакой визуальной среды разработки, даже простого редактора кода, в своем составе они не имеют.

Преимущества и недостатки
1. Visual C++ Build Tools 2015
Неудобная загрузка --- инсталлятор часто глючит
Необходим администраторский доступ для установки, следовательно, при переустановке системы надо заново устанавливать

2. Enterprise Windows Driver Kit (EWDK)
Легкая загрузка --- качаем единственный zip-архив

Формально, как написано в официальном сайте, для запуска скриптов необходим администраторский доступ, но можно работать и без этого; как --- опишу ниже. Официальный сайт предлагает пользоваться утилитой MSBuild, но в этом случае, чтобы скомпилировать даже простой "проект" "Hello, world", надо составить файл проекта .vcxproj, причем формат этого файла кое-в-чем отличается от, так скажем, стандартного. В статье Walkthrough: Using MSBuild to Create a Visual C++ Project приводится пример такого файла
Подробнее.
Однако, этот файл, скажем так, несколько устарел. Ниже приведен модифицированный мной пример MyTest.vcxproj
Подробнее.
Теперь можно и собирать:
MSBuild MyTest.vcxproj /p:configuration=release /p:platform=Win32

:: @call "%VS140COMNTOOLS%VCVarsQueryRegistry.bat" 32bit No64bit %1 %2

:: @call "%VS140COMNTOOLS%VCVarsQueryRegistry.bat" No32bit 64bit %1 %2

Ассемблер хорош для драйверов - они от набора команд ЦП зависят, а для ОС лучше ANSI C, или если одновременно нужно и считать и работать с большими массивами, и сложный ввод-вывод я предпочту PL/1 - скорость мало уступает ассемблеру, математика Fortran, работа с массивами лучше чем у Cobol и гибкость Algol,а сам код намного короче чем на C/C++ - я когда-то на нём писал систему виртуализации ресурсов майнфрейма - весь код вместе с GUI и ассемблерными вставками драйверов примерно 12 тыс строк,а на С пришлось бы написать около 400 тыс строк, да ещё и возится с их отладкой. Ну что проще записи вида

Dcl Arr1 array (A(j),T(n),D(u,x,y))

где индексы A(j),T(n),D(u,x,y) сами вложенные массивы? А если учесть, что индексов может быть до 63, и глубина вложенности массивов то же 63. Жаль что сейчас кроме старого IBM VisuaAge PL/1 под OS/2 и AS400 на него компиляторов толком нет. Модное ООП удобно, но если работать с мелочами когда сам можешь представить всю картину, а коли надо к примеру гидродинамику считать? Тяни монструозные библиотеки?

Идея-то отличная, только сколько на это труда уйдёт, да и у известной конторы только коробочки хорошо выходят. Они уж точно такую работу не потянут - банально не хватит знаний и умений ибо думать нонче очень не модно, а учится - "А зачем, коли добрые люди и так прокормят?". Поколение Митрофанушек из "Горе от ума".

TeXpert
Я лучше буду использовать boost, чем эти глупые нововведения в язык. Нужны потоки? Да в том же Qt они есть, организовано умно и красиво.

Кстати, если что - я большой поклонник ассемблера. Но для современного софта использовать его. ну не совсем практично.

Сможешь сделать вот это ?

Кстати, на первой странице еще обсуждалось использование Visual Studio Code, однако, постепенно энтузиазм пропал --- уж больно он жирный (exe-шник около 100 MB, это уж ни в какие ворота, наследие JavaScript?). А вот идея подбора легкой, гибко настраиваемой и кроссплатформенной IDE или продвинутого редактора остается. Претенденты: SciTE и QtCreator. Недостаток последнего --- требует инсталляции

Еще вопрос --- мне кажется, Visual Studio IDE существует в портабельном виде. Не требующей установки, просто распаковал архив и вперед. Может кто-нибудь слышал?

P. S. Я как-то натыкался на MSVC Standalone. Весьма любопытный проект, только про Visual Studio 2017. Прошу отписаться тех, кто проверял. Было бы еще лучше, если кто-нибудь переписал универсальный скрипт

[Временное решение] Невозможно установить Visual Studio в Windows. Ошибка: отказано в доступе. Механизм настройки

Я пытаюсь создать программу из ее исходного кода с помощью VC 11, и когда компилятор завершит работу, в заголовке появляется ошибка. Как я читал здесь и на других форумах, я уже пытался закрыть как можно больше программ и увеличить размер файла подкачки в Windows . они не работают.

Я читал о параметре \ Zm, но не понимаю, как его использовать.

Не могли бы вы мне помочь?

Взгляните на эту документацию, в которой приведены возможные решения:

У меня тоже была эта проблема, и я нашел документацию полезной. Основные положения:

Если компилятор также выдает ошибки C1076 и C3859, используйте параметр компилятора / Zm, чтобы снизить предел выделения памяти. Если вы уменьшите объем оставшейся памяти, вашему приложению станет доступно больше места в куче.
Если параметр / Zm уже установлен, попробуйте удалить его. Пространство кучи может быть исчерпано, потому что предел выделения памяти, указанный в параметре, слишком велик. Компилятор использует ограничение по умолчанию, если вы удалите параметр / Zm.
Если вы компилируете на 64-битной платформе, используйте 64-битный набор инструментов компилятора. Дополнительные сведения см. В разделе Как включить 64-разрядный набор инструментов Visual C ++ в командной строке.
В 32-битной Windows попробуйте использовать переключатель boot.ini / 3GB.
Увеличьте размер файла подкачки Windows.
Закройте другие запущенные программы.
Удалите ненужные включаемые файлы.
Устраните ненужные глобальные переменные, например, путем динамического выделения памяти вместо объявления большого массива.
Удалите неиспользуемые объявления.
Разделите текущий файл на файлы меньшего размера.

2 Для меня лучшим вариантом было использование 64-битного компилятора.

Я не могу много рассказать о параметре / Zm, но у меня была такая же проблема (компилятору не хватает места в куче).

Мне помог параметр / m: 4 (4 для количества ваших процессоров), так что вы можете использовать несколько процессоров для сборки.

Надеюсь, это поможет и вам.

У нас была аналогичная проблема: относительно простая программа (хотя и полная шаблонов, использующая библиотеку Eigen) постоянно не компилировалась на одном из компьютеров. Все использовали MSVC2013 x64, но только один не смог скомпилировать программу из-за ошибки C1060. Мы пробовали разные флаги компилятора, устанавливая / снимая -Zm, но не смогли разрешить это без изменения кода.

Однако некоторые указатели были нам предоставлены, когда мы переключились с версии компилятора x64 / x64 (64-битный компилятор для 64-битного исполняемого файла) на x86 / x86 (32-битный компилятор для 32-битного исполняемого файла). Компилятор x86 дал нам точное местоположение проблемных частей программы - вызовов шаблонных функций, получающих тяжелые шаблонные объекты. Мы переписали их на обычные функции (встроили в другой объектный файл), и это решило проблему .

В дополнение к другим ответам здесь (и в моем случае), fatal error C1060: compiler is out of heap space может быть вызвано синтаксической ошибкой. Следующий код (в определенных обстоятельствах) может вызвать эту ошибку даже при правильных параметрах компилятора - например, если вы ранее успешно скомпилировали ту же программу.

Кажется, это вызывает только эту ошибку, а не стандартную error C2143: syntax error: missing ')' before ';' когда r а также e относятся к определенным типам, но стоит проверить любой код, который вы недавно редактировали, если программа ранее скомпилировалась без ошибок.

VS: Visual Studio 2015 ОС: Windows10

Я пытаюсь собрать программу из ее исходного кода с VC 11, и когда компилятор собирается закончить, он вызывает ошибку в заголовке. Как я читал здесь и на других форумах, я попытался закрыть как можно больше программ и увеличить размер файла подкачки в Windows. они не работают.

Я читал о параметре \Zm, но я не понимаю, как его использовать.

Не могли бы вы мне помочь?

4 ответа

У меня тоже была эта проблема, и я нашел документацию полезной. Основные моменты:

Если компилятор также выдает ошибки C1076 и C3859, используйте параметр компилятора /Zm, чтобы уменьшить предел выделения памяти. Вашему приложению доступно больше пространства кучи, если вы уменьшите объем оставшейся памяти.
Если параметр /Zm уже установлен, попробуйте удалить его. Возможно, пространство кучи исчерпано, так как предел выделения памяти, указанный в параметре, слишком высок. Компилятор использует ограничение по умолчанию, если вы удалите опцию /Zm.
Если вы компилируете на 64-битной платформе, используйте 64-битный набор инструментов компилятора. Для получения дополнительной информации см. Как: включить 64-битный набор инструментов Visual C++ в командной строке.
В 32-битной Windows попробуйте использовать ключ /3GB boot.ini.

Я не могу много рассказать о параметре /Zm, но у меня была та же проблема (компилятору не хватает места в куче).

Что мне помогло, так это параметр /m:4 (4 для количества ваших процессоров), чтобы вы могли использовать несколько процессоров для сборки.

Надеюсь, это поможет вам.

Кроме того, если вы работаете на x64, убедитесь, что используются версии "msbuild.exe" и "cl.exe" для x64. У меня была проблема, что даже при использовании, например, x64 ms powershell, компилятор все равно выбирал 32-битную версию msbuild.exe (в диспетчере задач "msbuild.exe*32", windows 7)

У нас была похожая проблема: относительно простая программа (хотя и полная шаблонов, использующая библиотеку Eigen) постоянно не компилировалась на одном из компьютеров. Все использовали MSVC2013 x64, но только один не смог скомпилировать программу из-за ошибки C1060. Мы пробовали разные флаги компилятора, устанавливая / отменяя -Zm, но не смогли разрешить его без изменения кода.

Однако некоторые указатели были даны нам, когда мы перешли с версии компилятора x64/x64 (64-битный компилятор для 64-битного результирующего исполняемого файла) на версию x86/x86 (32-битный компилятор для 32-битного результирующего исполняемого файла). Компилятор x86 дал нам точное местоположение проблемных частей программы - вызовов шаблонных функций, получающих объекты с тяжелыми шаблонами. Мы переписали их в обычные функции (сборка в другом объектном файле), и это решило проблему.

В дополнение к другим ответам здесь (и в моем случае), fatal error C1060: compiler is out of heap space может быть вызвано синтаксической ошибкой. Следующий код (при определенных обстоятельствах) может вызвать эту ошибку даже с правильными параметрами компилятора - например, если вы ранее успешно скомпилировали ту же программу.

Кажется, только причиной этой ошибки, а не стандартной error C2143: syntax error: missing ')' before ';' когда r а также e относятся к определенным типам, но стоит проверить любой код, который вы недавно редактировали, если программа ранее была скомпилирована без ошибок.

Сразу скажу, что в финале мне удалось добиться сокращения времени компиляции решения с 4:24 минут до менее чем одной минуты. Детали под катом.

На старт!

В начале я собирался собрать отдельную тестовую машину с «чистой» ОС и одной лишь установленной программой — Visual Studio. Но потом решил, что тестировать сферических коней в вакууме будет не совсем верно. На компьютере программиста так или иначе будут установлены какой-нибудь браузер, антивирус, файловый менеджер, архиватор, текстовый редактор и т.д., а значит Студии придется работать со всем этим по близости. Значит, в таком режиме и будем её тестировать, на обычном компьютере разработчика (переустановив, правда, ради чистоты эксперимента, операционную систему и поставив свежие версии используемых в работе программ).

Набор экспериментов составлен по советом с сайтов Stackoverfow, RSDN, форумов MSDN, выдачи Google ну и просто из головы.

Объектом тестирования станет время полной компиляции решения. Перед каждым экспериментом вся папка проекта будет удаляться, код будет заново заливаться из репозитория, а Visual Studio перезагружаться. Каждый эксперимент будет повторяться трижды, результатом будет среднее время. После каждого эксперимента сделанные изменения откатываются.

Если кому-нибудь интересна аппаратная конфигурация моего компьютера, так вот она:

+ жесткий диск WD 500 Гб, 7200 RPM, 16 Мб кэш
+ Win 7 Профессиональная 32 бита со всеми возможными обновлениями
+ Visual Studio 2010 Professional с первым сервис-паком
В Windows включен режим максимальной производительности, отключен Aero и всякие анимации.

Исходное время компиляции моего решения: 4 минуты 24 секунды

Поехали!

Временные файлы — на RamDrive

Есть мнение, что самые медленные операции во время компиляции решения связаны с доступом к диску. Уменьшить это время можно путем использования RamDrive для временных файлов.
Результат: 4 минуты 13 секунд или -4.17% ко времени компиляции.

Вывод: прирост производительности имеется, хоть и небольшой. Если количество ОЗУ позволяет, этот совет можно применять в деле.

Весь проект — на RamDrive

Коль уж нам удалось немного ускорить компиляцию за счет выноса на RamDrive временных файлов, возможно получиться добиться еще лучших результатов, переместив туда всё решение (всё-таки более 4000 файлов).
Результат: 3 минуты 47 секунд или -14.02% ко времени компиляции.

Вывод: По началу этот эксперимент показался мне немного стрёмным — хранить исходники в оперативной памяти не лучший вариант (а вдруг пропадет питание?). Но, учитывая факт наличия бесперебойников, равно как и таких версий RamDrive, как от QSoft (с автоматическим дублированием измененных файлов с RamDrive на жесткий диск) убедили меня, что вариан возможен. Нужно только достаточно ОЗУ (и, по-хорошему, 64-битная ОС).

Весь проект — на флешку

Включение функции ReadyBoost в Windows

Microsoft расхваливает эту функцию именно за повышение производительности при работе с большим количеством относительно небольших блоков данных (наш вариант). Попробуем.
Результат: 4 минуты 17 секунд или -2.65% ко времени компиляции.

Вывод: вполне нормальный способ ускорения работы. Кроме необходимости 1 раз вставить флешку и настроить ReadyBoost других недостатков не имеет, а некоторый прирост производительности даёт.

Изменение количества одновременно компилирующихся проектов

Visual Studio при установке прописывает это число равным общему количеству ядер процессоров в Вашем ПК. Тем не менее, мы можем попробовать его изменить (делается это в настройках VS для С++ проектов) и оценить изменение производительности. Так как в моём компьютере 4-ядерный процессор, изначально это число было равным четырём.
Результат:
6 проектов компилируются одновременно — 4 минуты 34 секунды или +3.79% ко времени компиляции
2 проекта компилируется одновременно — 4 минуты 21 секунда или -1.14% ко времени компиляции

Вывод: я с самого начала ожидал, что увеличение числа одновременно компилирующихся проектов не даст никакого прироста производительности (так и вышло). Но вот почему уменьшение его до двух дало небольшой прирост для меня не очень понятно. Возможно, это просто статистическая погрешность, а может быть при компиляции 4-ех проектов Студия из-за их зависимостей теряет время на каком-то ожидании, что происходит реже при компиляции всего двух проектов. Если у кого-нибудь еще есть мысли по теме — прошу в комментарии.

Отключение вывода текста билда в окно Оutput

Меньше вывода текста при компиляции — быстрее результат.
Результат: 4 минуты 22 секунды или -0.76% ко времени компиляции

Вывод: прирост столь смехотворен, что не стоит даже комментариев. Он может быть как реальным, так и случайным.

Очистка корзины

Я вычитал этот совет на Stackoverflow. Аргументация была в том, что по ходу компиляции создаётся и удаляется масса мелких файлов, а процедура удаления в Windows работает медленнее при забитой корзине. Поскольку все предыдущие эксперименты я и так проводил при пустой корзине, мне пришлось проделать обратный эксперимент — положить в корзину 5000 файлов общим объёмом в 2 Гб.
Результат: 4 минуты 23 секунды или +0.38% ко времени компиляции.

Вывод: время компиляции осталось без изменений. Теория провалилась.

Ключ компилятора /MP

Ключ /MP — это тоже параллельная компиляция, но уже не проектов в решении, а файлов внутри каждого проекта.
Результат: 2 минуты 38 секунд или -40.15% ко времени компиляции

Вывод: это одно из самых существенных достижений среди всех поставленных экспериментов. Конечно, прирост столь высок в основном из-за 4-ядерности моего процессора, но вскоре такие (и еще более-ядерные процессоры) станут нормой в любом компьютере, так что включать опцию имеет смысл. При её включении компилятор честно предупреждает, что она не совместимо с ключом /Gm (Enable Minimal Rebuild), что вначале пугает — возникает мысль, что теперь при любом изменении любого файла будет происходить полная перекомпиляция решения. Так вот — нифига подобного! После изменения одного файла с кодом, как и ранее, будет перекомпилироваться только этот файл, а не всё решение. Всё, что делает ключ — это определяет выбор алгоритма определения взаимосвязей файлов кода и файлов заголовков в проекте (детальнее). Оба алгоритма неплохи и существенный прирост производительности от включения /MP во много раз превосходит недостатки от отключения /Gm.

Удаление папки решения из индекса поиска Windows

Есть мнение, что изменение файлов в папках, которые индексируются механизмом поиска ОС Windows, приводит к увеличению времени компиляции.
Результат: 4 минуты 24 секунды или никакого изменения во времени компиляции

Вывод: то ли индексирование в Windows сделано так хорошо, что вообще не замедляет работу других программ с диском, то ли это влияние минимально, то ли мне просто повезло и компиляция не совпала по времени с индексацией.

Unity Builds

Об этом механизме я рассказывал в прошлой статье.
Результат: 3 минуты 24 секунды или -22.73% ко времени компиляции.

Вывод: сокращение времени компиляции существенно. О всех достоинства и недостатках этой методики я уже писал, использовать его или нет Вы можете решить сами.

Завершение лишних программ

Работающие параллельно со Студией программы кушают память и ресурсы процессора. Их закрытие может положительно сказаться на скорости работы Студии. Итак, я закрываю Skype, QIP, Dropbox, GTalk, DownloadMaster, Mysql server.
Результат: 4 минуты 15 секунд или -3.41% ко времени компиляции

Вывод: во время компиляции придется обойтись без других программ. Никаких анекдотов и порнухи «пока оно там компилится». Вряд ли полный отказ от всех программ возможен для разработчика, но можно создать бат-файлы, включающие\выключащие все лишнее и иногда ими пользоваться.

Отключение антивируса

Если у Вас в системе установлен антивирус, то эта ~~сволочь~~ полезная программа постоянно проверяет все файловые операции. Таким образом, каждый участвующей в компиляции файл будет удостоен внимательного взгляда бдительного стража, что может замедлить время компиляции. Я, честно говоря, не был уверен, как настроить мой антивирус так, чтобы быть уверенным в полном игнорировании им моего проекта и попросту его удалил. Ваш антивирус, возможно, конфигурируется нужным образом.
Результат: 3 минуты 32 секунды или -19.07% ко времени компиляции

Вывод: удивительный результат. Я почему-то был уверен, что все эти *.cpp. *.h, *.obj файлы полностью антивирусом игнорируются и внимания удостоятся только скомпилированные исполняемые программы, что не очень сильно замедлит работу. Однако, факт налицо — почти минута времени экономии.

Дефрагментация жесткого диска

Файловые операции выполняются быстрее на дефрагментированом диске, а компиляция — это огромное количество файловых операций. Я специально оставил этот эксперимент напоследок, поскольку отменить дефрагментацию диска невозможно, а я хотел сделать эксперименты максимально независимыми.
Результат: 4 минуты 8 секунд или -6.06% ко времени компиляции

Вывод: практика согласуется с теорией. Поставьте себе дефрагментацию в планировщик и почаще.

Способы, которые, вероятно, помогли бы, но попробовать не вышло

Переход на 64-битную версию Windows

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

Обновление процессора, памяти, замена HDD на SSD или RAID

Нужно сказать, что моя тестовая машинка не так уж плоха и до планового апгрейда еще далеко. Работаем с тем, что есть. По отзывам в интернете наибольшее влияние на время компиляции оказывает установка SSD.

Вынесение редко меняющихся проектов в отдельное решение

Это и так уже было сделано. Если в Вашем проекте подобное еще не реализовано — обязательно займитесь.

Xoreax's IncrediBuild или аналог

Распределение компиляции между компьютерами — это уже достаточно кардинальный шаг. Он требует покупки специального ПО, серьёзной настройки и некоторого «выворачивания наизнанку» процесса сборки. Но в очень больших проектах это может стать единственным возможным вариантом. На сайте Xoreax's IncrediBuild есть данные по приросту производительности, рассказы клиентов и куча ~~другого спама~~ разной полезной информации по теме.

Это всё, что я хотел рассказать о способах ускорения компиляции решений в Visual Studio, а в следующей статье я приведу несколько советов по ускорению работы самой IDE.

Читайте также: