Объем потребляемой памяти Python по сравнению с размером "кучи"
В Objective-C (iOS и OSX) просто запомните эти макросы:
#define INT8_MAX 127
#define INT16_MAX 32767
#define INT32_MAX 2147483647
#define INT64_MAX 9223372036854775807LL
#define UINT8_MAX 255
#define UINT16_MAX 65535
#define UINT32_MAX 4294967295U
#define UINT64_MAX 18446744073709551615ULL
4 ответа
Реализация CPython только в исключительных случаях освобождает выделенную память. Это широко известная ошибка, но разработчики CPython не уделяют ей особого внимания. Рекомендуемый обходной путь - "разветвить и умереть" процесс, который потребляет много оперативной памяти.
Python выделяет объекты Unicode из кучи C. Поэтому, когда вы выделяете много из них (вместе с другими блоками malloc), а затем освобождаете большинство из них, за исключением самого последнего, C malloc не будет возвращать память операционной системе, так как куча C будет сжиматься только в конце ( не посередине). Освобождение последнего объекта Unicode освободит блок в конце кучи C, что затем позволит malloc вернуть все это в систему.
Помимо этих проблем, Python также поддерживает пул освобожденных объектов unicode для более быстрого распределение. Поэтому, когда последний объект Unicode освобождается, он не возвращается сразу в malloc, в результате чего все остальные страницы "зависают".
Какую версию Python вы используете?
Я спрашиваю, потому что более старая версия CPython не освобождает память , и это было исправлено в Python 2.5.
Я реализовал совет Хруске "вилка и смерть". Я использую os.fork () для выполнения участка кода, интенсивно использующего память, в дочернем процессе, а затем позволяю дочернему процессу выйти. Родительский процесс выполняет os.waitpid () для дочернего, так что в данный момент времени выполняется только один поток.
Если кто-нибудь обнаружит какие-либо подводные камни с этим решением, пожалуйста, свяжитесь с нами.