Максимальная.NET достижимая память?
Я бы просто использовал простую функцию, которую все поймут. Для меня это легко и элегантно.
function getFragArray($arrayValues, $arrayKey) {
$resu = [];
foreach ($arrayValues as $key=>$value) {
if(in_array($value,$arrayKey)) {
$resu[$key] = $value;
}
}
return $resu;
}
9 ответов
Нет никакого трудного, точного числа для кода.NET.
Если Вы работаете на Windows на 32 бита; Ваш процесс может обратиться к 2 ГБ, 3 ГБ, если переключатель/3GB используется на Windows Server 2003.
При выполнении процесса на 64 бита на поле на 64 бита процесс может обратиться к 8 ТБ адресного пространства, если так много RAM присутствует.
Это не целая история однако, так как CLR берет немного служебные для каждого процесса. В то же время.NET попытается выделить новую память в блоках; и если адресное пространство фрагментируется, который мог бы означать, что Вы не можете выделить больше памяти, даже при том, что некоторые доступны.
В C# 2.0 и 3.0 существует также предел 2G на размер отдельного объекта в управляемом коде.
Объем памяти, к которому может обратиться Ваш процесс.NET, зависит и от того, работает ли он на машине на 32/64 бита и действительно ли это это работающий как агностик ЦП или ЦП определенный процесс.
По умолчанию процесс.NET является агностиком ЦП, таким образом, он будет работать с типом процесса, который является естественным для версии Windows. В 64 битах это будет процесс на 64 бита, и в 32 битах это будет процесс на 32 бита. Можно вызвать процесс.NET, хотя быть нацеленными на конкретный ЦП и сказать, заставляют его работать как процесс на 32 бита на машине на 64 бита.
При исключении большого адреса осведомленная установка следующее является различными разбивками
- Процесс на 32 бита может обратиться к 2 ГБ
- Процесс на 64 бита может обратиться к 8 ТБ
Вот ссылка на полную разбивку адресуемого пространства на основе Windows различных вариантов, обеспечивает.
Да, в среде на 32 бита Вы ограничены адресным пространством на 4 ГБ, но требованиями Windows приблизительно половина. На архитектуре на 64 бита это, ну, в общем, намного больше. Я полагаю, что это - 4G * 4G
И на Компактной Платформе это обычно находится в порядке нескольких сотен МБ
Для Windows на 64 бита размер виртуальной памяти составляет 16 ТБ, разделенных одинаково между непривилегированным и привилегированным режимом, таким образом, пользовательские процессы могут обратиться к 8 ТБ (8 192 ГБ). Это - меньше, чем все 16 пространств EB, адресуемых на 64 бита, но это все еще намного больше, чем, к чему мы привыкли с 32 битами.
Время выполнения.NET может выделить всю свободную память, доступную для программ непривилегированного режима в его хосте. Следите за этим, это не означает, что вся та память будет выделена Вашей программе, как некоторые (относительно небольшие) части будут выделены внутренним структурам данных CLR. В системах на 32 бита, принимая 4 ГБ или большем количестве установки (даже если PAE включен), необходимо смочь получить самое большее примерно 2 ГБ, выделенных приложению. В системах на 64 бита необходимо смочь получить 1 ТБ. Для получения дополнительной информации касающиеся пределы памяти окон, рассмотрите эту страницу. Каждая фигура упомянула, там должен быть разделен на 2, поскольку окна резервируют более высокую половину адресного пространства для использования кодом, работающим в привилегированном режиме (звоните 0). Кроме того, возражайте против этого каждый раз, когда для системы на 32 бита предел превышает 4 ГБ, использование PAE подразумевается, и таким образом Вы все еще не можете действительно превысить предел на 2 ГБ, если ОС не поддерживает 4gt, в этом случае можно достигнуть до 3 ГБ.
Я думаю другие ответы, являющиеся довольно наивным в реальном мире после 2 ГБ потребления памяти, Ваше приложение будет вести себя действительно плохо. По моему опыту, графический интерфейсы пользователя обычно идут в широком масштабе неуклюжие, unsusable после большого потребления памяти.
Это было моим опытом, очевидно фактической причиной этого могут быть объекты, становится слишком большим, таким образом, все операции на тех объектах занимают слишком много времени.
The following blog post has detailed findings on x86 and x64 max memory. It also has a small tool (source available) which allows easy easting of the different memory options: http://www.guylangston.net/blog/Article/MaxMemory.
В последнее время я занимаюсь обширным профилированием памяти в .NET в 32-битном процессе. Нас всех бомбардирует мысль, что мы можем выделить до 2.4 Гб (2^31) в .NET-приложении, но, к сожалению, это не так :(. Процесс работы с приложением занимает столько места, и операционная система отлично справляется с ним, однако, сама .NET, похоже, имеет свои собственные накладные расходы, которые составляют примерно 600-800 МБ для типичных реальных приложений, которые превышают лимит памяти. Это означает, что как только вы выделяете массив целых чисел, который занимает около 1.4Гб, вы должны ожидать появления функции OutOfMemoryException().
Очевидно, что в 64-битном варианте этот лимит возникает гораздо позже (давайте пообщаемся через 5 лет :)), но общий размер всего в памяти также увеличивается (я нахожу, что это ~1. От 7 до ~2 раз) из-за увеличенного размера слова.
Я точно знаю, что идея виртуальной памяти от операционной системы определенно НЕ дает практически бесконечное пространство для выделения в рамках одного процесса. Она только там, чтобы полные 2,4 Гб были адресованы всем (многим) приложениям, запущенным за один раз.
Я надеюсь, что это понимание несколько поможет.
Я изначально ответил на что-то связанное с этим (я все еще новичок, так что не уверен, как я должен делать эти ссылки):