Недостатки чтения и записи большого файла на диск или с диска сразу вместо маленьких кусков?

Question

Я работаю в основном на системах Windows и Windows CE, где CreateFile, ReadFile и WriteFile - рабочие лошадки, независимо от того, нахожусь ли я на родной земле Win32 или на управляемой .Net земле.

У меня до сих пор никогда не было очевидных проблем с записью или чтением больших файлов в одном чанке, в отличие от зацикливания до обработки нескольких меньших чанков. Обычно я делегирую работу ввода-вывода фоновому потоку, который уведомляет меня о завершении.

Но, глядя на учебники по IO файлов или «примеры из учебников», я часто нахожу «цикл с небольшими кусками», используемый без какого-либо объяснения того, почему он используется вместо более очевидного (осмелюсь сказать!) «Сделать все это в один раз».

Есть ли у меня какие-то недостатки, которые я не понял?

Пояснение:

По большой файл Я сравнил свой отдельный кусок с несколькими. Упомянутые мною примеры с несколькими чанками часто имеют размеры чанков в 1024 байта в Windows CE и в 10 раз больше на рабочем столе. Мои большие файлы обычно представляют собой двоичные файлы, такие как фотографии с камер с мобильных телефонов и т. Д., И в таком порядке порядка 2-10 МБ. Другими словами, не близко к 1 ГБ.

Answer 1

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

Тогда возникает вопрос с памятью: предположим, кто-то просит вас обработать файл размером 3 ГБ. Если вы транслируете его, обрабатывая порцию за раз, у вас нет проблем. Если вы попытаетесь прочитать все это в памяти, вам вряд ли удастся ...

В общем: если вы можете транслировать его, сделайте. Почему вы хотите использовать менее надежный и менее эффективный подход? Для любого вида надежности вам все равно придется проверить возвращаемое значение Read и сравнить его с тем, сколько вы ожидали прочитать ... поэтому добавление цикла не вызовет очень большой сложности. Кроме того, если вы обнаружите, что делаете это много, вы можете обнаружить шаблоны, которые вы можете инкапсулировать в вспомогательные методы, вполне возможно, что делегаты будут представлять пользовательские действия, выполняемые для обработки.

Answer 2

Это зависит от вашего определения "большой". Удачи в чтении 10 ГБ файла в память, если у вас всего 2 ГБ ОЗУ (не считая виртуальной памяти).

Итак, говоря в общих чертах, вам всегда нужно будет делать чанкинг. Вероятно, поэтому учебники так любят это. Это просто размер кусков, который является предметом обсуждения.

Дополнительным преимуществом разбиения на блоки при обработке потока является то, что использование памяти поддерживается низким и не зависит от размера ввода.

Однако, если ( и только если ) вы знаете, что есть некоторая верхняя граница для размера вашего файла и нижняя граница для вашей оперативной памяти, вы можете сделать все это сразу.