Плюсы и минусы использования SetProcessWorkingSetSize

Ответ 1

SetProcessWorkingSetSize() контролирует объем оперативной памяти, который использует ваш процесс, в противном случае он не влияет на размер виртуальной памяти вашего процесса. Windows уже хорошо справляется с динамическим контролем этого, сворачивая страницы памяти по требованию, когда другой процесс нуждается в ОЗУ. Выполняя это вручную, вы значительно замедляете свою программу, вызывая множество сбоев страницы, когда Windows вынуждена заменять страницы памяти. SetProcessWorkingSetSize обычно используется для увеличения объема ОЗУ, выделенного для процесса. Или заставить обрезать, когда приложение знает, что он будет простаивать в течение длительного времени. Также выполняется автоматически с помощью старых версий Windows, когда вы сворачиваете главное окно приложения.

Не нужно пинквировать этот бит, вы можете использовать свойства Process.GetCurrentProcess.Min/MaxWorkingSet.

Ответ 2

Единственный хороший вариант использования, который я видел для этого вызова, - это когда вы ЗНАЕТЕ, что ваш процесс будет запугать много системной RAM, и вы хотите зарезервировать его на время. Вы используете его, чтобы сообщить ОС "Да, я собираюсь съесть много системной памяти в течение всего моего прогона и не мешаю мне".

В этой ситуации, оставляя поведение ОС по умолчанию, является плохим. ОС выделяет по умолчанию # МБ ОЗУ для каждого process- в основном своего рабочего пространства. Эвристика управления ресурсами - это не оракулы, поэтому, если они обнаруживают, что какой-то процесс питания больше, чем его доля в системных ресурсах (например, ОЗУ), они будут пытаться отбить как можно больше избытка. Для ВАШЕГО процесса это означает, что ОС будет тратить много CPU (и, следовательно, повредить вашу производительность), используя пейджинговую память в и из вашего адресного пространства, когда это не нужно.

Ответ 3

Мы обнаружили, что для приложения с графическим интерфейсом, написанного на Delphi для Win32/Win64 или аналогичным образом, использующего большие и тяжелые библиотеки поверх Win32 API (GDI и т.д.), Стоит один раз вызвать SetProcessWorkingSetSize.

Мы вызываем его с параметрами -1, -1 в течение доли секунды после того, как приложение полностью открылось и показало пользователю главное окно. В этом случае SetProcessWorkingSetSize (... -1, -1) освобождает много кода запуска, который, по-видимому, больше не нужен. Память быстро восстанавливается примерно до 1/3 того, что была бы без SetProcessWorkingSetSize (... -1, -1), и с тех пор не увеличивается (если приложение не выделяет больше памяти). Таким образом, мы эффективно сэкономили 2/3 памяти в основном кода запуска (загрузка и анализ файлов конфигурации, инициализация графического интерфейса и т.д.), Которые, возможно, никогда не требовались.

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

Даже для серверного (сервисного) приложения, у которого нет GUI - я думаю, что вызов SetProcessWorkingSetSize один раз после полной загрузки и инициализации сервера, возможно, был бы полезен.