Как увеличить память процесса в visual studio
Обновлено: 03.07.2024
Сразу скажу, что в финале мне удалось добиться сокращения времени компиляции решения с 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.
Рекомендации по повышению производительности Visual Studio предназначены для редких ситуаций, когда может возникать нехватка памяти. В таких случаях можно оптимизировать определенные компоненты Visual Studio, которые могут не использоваться. Приведенные ниже советы не следует рассматривать как общие рекомендации.
Если при работе с продуктом у вас возникают затруднения из-за проблем с памятью, свяжитесь с нами через средство обратной связи.
Использование 64-разрядной ОС
При переходе с 32-разрядной на 64-разрядную версию Windows вы увеличиваете объем виртуальной памяти, доступной Visual Studio, с 2 до 4 ГБ. Это позволяет Visual Studio обрабатывать значительно большие рабочие нагрузки даже несмотря на то, что это 32-разрядный процесс.
Visual Studio 2022 для Windows теперь является 64-разрядным приложением. Это означает, что вы можете открывать, изменять, запускать и отлаживать даже самые большие и сложные решения, не беспокоясь о нехватке памяти. Дополнительные сведения см. в записях блога, посвященных концепции Visual Studio 2022 и Visual Studio 2022, предварительная версия 1.
Отключение автоматического восстановления файлов
Visual Studio автоматически повторно открывает документы, открытые во время предыдущего сеанса. Это может увеличить время загрузки решения до 30 % или более в зависимости от типа проекта и открываемых документов. Конструкторы, например Windows Forms и XAML, и некоторые файлы JavaScript и typescript могут открываться медленно.
Visual Studio отображает уведомление на желтой панели, если автоматическое восстановление документа значительно замедляет загрузку решения. Вы можете отключить автоматическое повторное открытие файлов, выполнив следующие действия.
Выберите пункты меню Сервис > Параметры, чтобы открыть диалоговое окно Параметры.
На странице Проекты и решения > Общие отмените выбор пункта Повторно открыть документы при загрузке решения.
Если отключить автоматическое восстановление файлов, быстро перейти к нужным файлам можно с помощью одной из команд Перейти к:
Чтобы использовать общие функции Перейти к, выберите Изменить > Перейти к > Перейти ко всем или нажмите CTRL+T.
Перейдите к последней правке в решении, выбрав Изменить > Перейти к > Перейти к последнему изменению или нажав CTRL+SHIFT+BACKSPACE.
Используйте Перейти к последнему файлу, чтобы просмотреть список недавно просмотренных файлов в решении. Выберите Изменить > Перейти к > Перейти к последнему файлу или нажмите CTRL+1, CTRL+R.
Настройка параметров отладки
Если вы часто сталкиваетесь с нехваткой памяти во время сеансов отладки, можно оптимизировать производительность, внеся одно или несколько изменений в конфигурацию.
Включение функции "Только мой код"
Чтобы включить функцию Только мой код, выберите Сервис > Параметры > Отладка > Общие и затем Включить только мой код.
Указание символов для загрузки
При отладке машинного кода для загрузки файлов символов ( .pdb) требуется большой объем памяти. Вы можете настроить параметры отладочных символов для экономии памяти. Как правило, решение настраивается для загрузки только модулей из проекта.
Чтобы указать загрузку символов, выберите Сервис > Параметры > Отладка > Символы.
Задайте параметр Только указанные модули вместо Все модули и затем укажите, какие модули нужно загружать. Во время отладки также можно щелкнуть определенные модули правой кнопкой мыши в окне Модули, чтобы явно включить модуль в загрузку символов. (Чтобы открыть окно во время отладки, выберите Отладка > Окна > Модули.)
Дополнительные сведения см. в разделе Общие сведения о файлах символов.
Отключение средств диагностики
Рекомендуется отключить профилирование ЦП после использования. Эта функция может потреблять очень много ресурсов. После включения профилирования ЦП это состояние распространяется и на все последующие сеансы отладки, поэтому его следует отключать явным образом. Вы можете сэкономить ресурсы, отключив средства диагностики при отладке, если некоторые предоставляемые функции вам не нужны.
Для отключить Средства диагностики, запустите сеанс отладки, выберите Средства > Параметры > Отладка > Общие и снимите флажок Включить средства диагностики при отладке.
Дополнительные сведения см. в статье Средства профилирования.
Отключение инструментов и расширений
Для повышения производительности можно отключить некоторые инструменты или расширения.
Часто проблемы производительности можно выявить, отключая расширения по одному и проверяя уровень производительности.
Управляемые службы языка (Roslyn)
Отключение полного анализа решения
Отключение CodeLens
Visual Studio выполняет задачу Найти все ссылки для каждого метода при его отображении. CodeLens предоставляет такие функции, как встроенное отображение числа ссылок. Эта работа выполняется в отдельном процессе, например ServiceHub.RoslynCodeAnalysisService32. В крупных решениях или системах с небольшим объемом ресурсов эта функция может значительно снижать производительность. В случае возникновения проблем с памятью, например при загрузке большого решения на компьютере с 4 ГБ памяти или высокой загрузки ЦП при выполнении этого процесса, попробуйте отключить CodeLens для высвобождения ресурсов.
Чтобы отключить CodeLens, выберите Сервис > Параметры > Текстовый редактор > Все языки > CodeLens и отмените выбор данной функции.
Функция CodeLens доступна в выпусках Visual Studio Professional и Enterprise.
Другие инструменты и расширения
Отключение расширений
Расширения — это дополнительные программные компоненты в Visual Studio, которые предоставляют новые или расширяют имеющиеся функциональные возможности. Расширения часто могут выступать источником проблем с памятью. При возникновении подобных проблем попробуйте отключать расширения по одному за раз, чтобы оценить, как это влияет на сценарий или рабочий процесс.
Чтобы отключить расширения, перейдите в раздел Сервис > Расширения и обновления и отключите нужное расширение.
Чтобы отключить расширения, перейдите в меню Расширение > Управление расширениями и отключите нужное расширение.
Отключение режима карты
В режиме карты на полосе прокрутки показывается миниатюрное изображение строк кода. Режим карты включен по умолчанию.
Чтобы отключить режим карты, последовательно выберите Инструменты > Параметры > Текстовый редактор > Все языки > Полосы прокрутки, а затем в разделе Поведение снимите флажок Использовать режим карты для вертикальной полосы прокрутки.
Отключение переноса по словам
При включенном переносе по словам отображается часть длинной строки кода, выступающая за пределы текущей ширины окна редактора кода. Перенос по словам включен по умолчанию.
Чтобы отключить перенос по словам для проекта, над которым вы работаете в текущий момент, последовательно выберите в меню пункты Правка > Дополнительно > Перенос по словам. (Этот параметр можно переключать с помощью одних и тех же команд меню.)
Чтобы отключить перенос по словам для всех проектов, последовательно выберите в меню пункты Инструменты > Параметры > Общие > Текстовый редактор > Все языки > Общие, а затем в разделе Параметры снимите флажок Перенос по словам.
Отключение конструктора XAML
Конструктор XAML по умолчанию включен, но потребляет ресурсы только при открытии файла .xaml. Если вы работаете с XAML-файлами, но не хотите использовать функциональные возможности конструктора, отключите его, чтобы освободить память.
Чтобы отключить конструктор XAML, последовательно выберите в меню пункты Инструменты > Параметры > Конструктор XAML > Включить конструктор XAML, а затем снимите этот флажок.
Удаление рабочих нагрузок
Если вы не собираетесь использовать определенные рабочие нагрузки, удалите их с помощью установщика Visual Studio. Это позволяет оптимизировать расходы ресурсов при запуске и выполнении за счет пропуска ненужных пакетов и сборок.
Добавление неотслеживаемых файлов в локальный файл .gitignore
Visual Studio выполняет команду Git git status для неотслеживаемых файлов, чтобы вам было удобно добавлять новые файлы в репозиторий. При наличии большого количества неотслеживаемых файлов git status может потреблять большой объем памяти. Чтобы сделать эти файлы игнорируемыми и повысить производительность git status , можно добавить такие файлы или папки в локальный файл .gitignore. Чтобы получить доступ к файлу, выберите Git > Параметры > Параметры репозитория Git. Затем в разделе файлы Git щелкните Добавить, чтобы создать файл .gitignore, или щелкните изменить, если он у вас уже есть.
Принудительная сборка мусора
Среда CLR использует систему управления памятью, подразумевающую сборку мусора. В этой системе память иногда используется объектами, которые больше не нужны. Это временное состояние — сборщик мусора освободит эту память, основываясь на своей эвристике производительности и использования ресурсов. Вы можете заставить среду CLR собрать всю неиспользуемую память, используя сочетание клавиш в Visual Studio. Если имеется значительный объем мусора, ожидающего сборки, то принудительная сборка мусора позволяет снизить использование памяти процессом devenv.exe в диспетчере задач. Потребность в этом методе возникает довольно редко. Тем не менее после завершения операции, потребляющей много ресурсов (такой как полная сборка, сеанс отладки или событие открытия решения), он может помочь определить объем памяти, действительно используемый процессом. Так как среда Visual Studio является смешанной (управляемый и машинный код), собственный распределитель и сборщик мусора могут конкурировать за ограниченные ресурсы памяти. В условиях высокого использования памяти это может помочь принудительно запустить сборщик мусора.
Чтобы принудительно запустить сборку мусора, используйте сочетание клавиш: CTRL+ALT+SHIFT+F12, CTRL+ALT+SHIFT+F12 (нажмите два раза).
Если принудительная сборка мусора обеспечивает работоспособность сценария, направьте отчет с помощью средства обратной связи Visual Studio, так как подобное поведение, скорее всего, указывает на ошибку.
Подробное описание сборщика мусора CLR см. в статье Основы сборки мусора.
Я хочу отобразить 4 миллиона треугольников в моем программном обеспечении на базе windows, написанном в Visual Studio c/" >C++ 2010 (сборка в режиме выпуска). Когда я рендеринг 3.9 миллионов треугольников, общая память ОЗУ, потребляемая программным обеспечением, составляет 400 МБ. Но когда я пытаюсь отобразить 4 миллиона треугольников (всего на 100 тысяч больше), система дает мне ошибку.
Я должен выделить память для вершин, нормалей лица, нормалей вершины и т. д.
На самом деле то, что я не получаю, у меня есть 8 ГБ оперативной памяти, (но в 32 бит XP windows = 3.2 ГБ памяти), а программное обеспечение просто зарезервировано 400 МБ, свободная память больше 1 ГБ, но когда я пытаюсь отобразить только 100k треугольников больше, это дает мне ошибку. Почему это дает мне ошибку? потому что он по-прежнему имеет более 1 ГБ свободной оперативной памяти?
пожалуйста, руководство меня. Спасибо.
Я много пробовал, изменяю код, удаляю утечки памяти и т. д., Но я не могу выделить память более 4 миллионов. Его невозможно измените весь мой код на "вектор". Я не могу перейти в "вектор", я должен застрять на своей собственной структуре данных теперь с "новым". Ниже приведены указатели, которые я хочу выделить для рендеринга 1 объекта.
Это один из великих мифов программирования Windows, процесс может никогда закончился ОЗУ. Windows-это операционная система виртуальной памяти с подкачкой по запросу, если процессу требуется больше оперативной памяти, операционная система освобождает место, подкачивая другие страницы памяти, принадлежащие другим процессам. Или сам процесс, замена страниц, которые не использовались в течение некоторого времени.
этот миф поощряется тем, как Диспетчер задач сообщает об использовании памяти для процесса с его значением по умолчанию настройки. Это показывает рабочий набор, фактическое количество байтов процесса, которые находятся в ОЗУ. Значение, которое обычно намного меньше объема виртуальной памяти, выделенной процессом. Процесс умирает на OOM, когда он не может выделить виртуальный. Другая статистика в Taskmgr, значение размера VM. И он обычно умирает не потому, что все VM были использованы, а потому, что не осталось достаточно большой дыры. Утилита VMMap SysInternals-хороший способ увидеть как процесс использует свое адресное пространство.
получение большего адресного пространства виртуальной памяти требует довольно фундаментального пересмотра. Хотя это легко сегодня, просто цель x64 в качестве целевой платформы. 64-разрядный процесс имеет огромное количество доступного адресного пространства, ограничивается только максимальный размер файла подкачки. Вы можете хромать в 32-разрядном режиме, пока вы можете рассчитывать на фактический запуск в 64-разрядной операционной системе, используя параметр /LARGEADDRESSAWARE linker. Который увеличивает размер виртуальной машины с 2 ГБ до 4 ГБ в 64-разрядной операционной системе.
для одного из вопросов:
is there any diffirence between these two?
разница между new и malloc заключается в следующем:
malloc используется в C, malloc выделяет неинициализированную память. Выделенная память должна быть освобождена с free .
new инициализирует выделенную память, вызывая соответствующий конструктор. Выделенную память с new должен быть освобожден с delete (который вызывает деструктор.) Вам не нужно указывать размер блока памяти, чтобы освободить выделенную память.
не ясно ли new и malloc связаны в соответствии со стандартом (это зависит от того, реализует ли конкретный компилятор new используя malloc или нет), поэтому проблема может или не может быть решена путем простой замены new С malloc .
из кода, который вы показали, трудно определить причину ошибки. Вы можете попробовать чтобы заменить динамический массив на vector чтобы увидеть, если это решает вашу проблему. Между тем, вы можете использовать valgrind чтобы проверить, есть ли у вас утечка памяти в коде (если вы можете каким-то образом перенести свой код в Linux с makefiles, так как, к сожалению, valgrind недоступен в Windows.).
есть разница между malloc и new , например, new инициализирует вашу память и автоматически вызывает конструктор класса. Или инициализировать, если они являются примитивными типами (например, float , int , char и т. д.). Также память, выделенная new следует удалить с помощью delete ключевое слово, которое вызывает деструктор.
С malloc() а также new оператор в Visual Studio внутренний вызов HeapAlloc() . HeapAlloc() звонки VirtualAlloc() если требуемая память слишком велика или используется совместно процессами. Таким образом, это не обязательно исправит вашу проблему. Infact, если вы используете c++ stick для использования new .
Как увеличить максимальную память, выделенную для стека/кучи для программы на С++?
Увеличивает ли оперативная память вашего компьютера автоматическое увеличение памяти стека/кучи компьютерной программы?
ОТВЕТЫ
Ответ 1
Ответ 2
Второе редактирование: я вижу из вашего комментария, что вы работаете в Windows, поэтому мой ответ Unix ниже не будет очень полезен для вас. Но см. Определение пространства стека с помощью Visual Studio и максимальный размер стека для C/С++.
Размер stack довольно ограничен в Linux. Команда ulimit -s даст текущее значение в килобайтах. Вы можете изменить значение по умолчанию (обычно) в файле /etc/security/limits.conf.
Вы также можете, в зависимости от привилегий, изменить его на основе каждого процесса с помощью setrlimit() . См. Например мой ответ в Ошибка сегментации: выделение стека в программе на языке C в Ubuntu, когда bufffer > 4M.
Для кучи см., например, ограничение размера кучи в C. Но я не думаю, что вы можете увеличить или уменьшить максимальный размер.
Ответ 3
Вы можете указать размер зарезервированной кучи и размер стека с параметрами link/Heap и /Stack в Visual Studio. Подробнее см. В следующих статьях MSDN:
Ответ 4
Размер кучи процесса обычно ограничен максимальной памятью, которую может выделить процесс. Куча не должна быть смежной (если вы не делаете что-то вроде malloc (1000000000)), поэтому куча может использовать большую часть доступного адресного пространства.
В Windows максимальный размер процесса зависит от нескольких факторов.
Используя 32-разрядную Windows, 32-разрядный процесс может по умолчанию выделять 2 ГБ. Если Windows загружается с помощью переключателя /3GB, и процесс компилируется с использованием флага компоновщика "Разрешить большие адреса", тогда процесс может выделить 3 ГБ.
Используя 64-битную Windows, 32-разрядный процесс по умолчанию может выделять 2 ГБ. Если процесс связан с "Разрешить большие адреса", то 64-разрядная версия Windows позволяет 32-битовому процессу выделять 4 ГБ.
64-разрядный процесс (в 64-разрядной Windows) может выделить примерно 16 000 ГБ.
Ответ 5
У меня возникла проблема с памятью с размером кучи по умолчанию и размером в 1 МБ. Но когда я устанавливаю свойства выше 2 МБ (2000000), он отлично работает.
Чтобы установить эти свойства в среде разработки Visual Studio, выполните следующие действия.
Читайте также: