2013-07-29 3 views
1

У меня возникают проблемы с исключениями из памяти при использовании .Net MemoryStream, если данные большие, а процесс 32 бит.альтернатива MemoryStream для больших объемов данных

Я считаю, что API-интерфейс System.IO.Packaging без проблем переключается из памяти в хранилище с файловым хранилищем по мере увеличения объема данных, и на первый взгляд кажется, что можно реализовать подкласс MemoryStream, который делает то же самое.

Кто-нибудь знает о такой реализации? Я почти уверен, что в самой структуре ничего нет.

+0

Без информации о том, как вы используете этот «MemoryStream», очень сложно сделать конкретную рекомендацию. –

ответ

0

Ожидается, что это произойдет с использованием MemoryStream, поэтому вы должны реализовать свою собственную логику или использовать какой-либо внешний класс. вот сообщение, которое объясняет проблемы с MemoryStream и большими данными, и сообщение дает альтернативу MemoryStreamA replacement for MemoryStream

+0

Спасибо, я нашел это раньше, но их MemoryTributary позволяет примерно удвоить размер данных стандартного MemoryStream, поэтому это не общее решение. – Andy

6

Программисты слишком стараются, чтобы избежать использования файла. Разница между памятью и файлом очень маленькая в Windows. Любая память, которую вы используете для MemoryStream, фактически требует наличия файла. Хранилище поддерживается файлом подкачки, c: \ pagefile.sys. И обратное верно, а любой файл, который вы используете, поддерживается памятью. Файловые данные кэшируются в ОЗУ кэшем файловой системы. Поэтому, если машина имеет достаточное количество оперативной памяти, тогда вы фактически будете читать и записывать из/в память, если используете FileStream. И получите перфоманс, который вы ожидаете от использования памяти. Это абсолютно бесплатно, вам не нужно писать какой-либо код, чтобы включить это, и вам не нужно управлять им.

Если на машине недостаточно памяти, она ухудшается одинаково. Когда вы используете MemoryStream, файл подкачки запускается с ошибкой, и вы будете замедлены диском. Когда вы используете файл, данные не будут соответствовать кешу файловой системы, и вы будете замедлены на диске.

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

+0

-1 Есть много моментов, которые, как я считаю, ошибочны в этом ответе, но в интерес к космосу я буду только оспаривать это: «Так что если машина имеет достаточную оперативную память, то на самом деле вы будете только читать и писать из/в память, если используете FileStream». Это абсолютно неверно. В настоящее время я работаю над проектом, в котором я пишу 3 ГБ для FileStream в системе с объемом памяти более 50 ГБ. И я могу сказать вам, что он постоянно сохраняется на диске. И MemoryStreams нет. –

+0

Существует еще один термин, благоприятствующий потоку файлов 3 ГБ по потоку памяти на такой машине, он называется «делать это неправильно». Отправьте свой собственный ответ. –

+0

@ HansPassant Старый пост, но очень хороший намек! – YvesR

-1

Я предлагаю проверить этот проект.

http://www.codeproject.com/Articles/348590/A-replacement-for-MemoryStream

Я считаю, что проблема с памятью потоков исходит из того, что под всем этим они все еще фантазии обертка для одного байта [] и поэтому по-прежнему сдерживается требованием .NET, что все объекты должны быть менее 2 ГБ даже в 64-битных программах. Вышеупомянутая реализация разбивает байт [] на несколько разных байтов [] s.

Смежные вопросы