Лучший шаблон поиска файлового потока для двоичного файла в .NET/Windows

Я пытаюсь прочитать двоичный файл, в котором интересующие меня данные разделены по файлу. Какой шаблон чтения лучше? (предположим, что начальная позиция потока находится в байте 0)

  1. чтение (счетчик = 8192), поиск (смещение = 20480, источник = текущий), чтение (счетчик = 8192), поиск (смещение = 12288, источник = текущий)
  2. чтение (счетчик = 8192), поиск (смещение = 28672, происхождение = начало), чтение (счетчик = 8192), поиск (смещение = 49152, происхождение = начало)

Поскольку потоки .NET позволяют мне выбирать SeekOrigin, какой шаблон поиска лучше: тот, который начинается с SeekOrigin.Begin, или тот, который продолжает поиск с позиции SeekOrigin.Current?

Это имеет значение? Разве ОС не может сама сделать расчет и решить за меня?


person Paul    schedule 29.07.2012    source источник


Ответы (1)


Это не имеет значения. SeekOrigin.Current — это просто удобная опция, которая помогает вам не отслеживать абсолютную позицию самостоятельно. Windows уже делает это внутри, поэтому у нее нет проблем с преобразованием текущего смещения в начальное смещение. Что ему действительно нужно. Как вы поняли, что ОС может автоматически искать 20480, а затем 12288, непонятно. Не может, Windows не имеет понятия о размере записи. Файл — это просто поток байтов, на него не накладывается никакой структуры.

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

person Hans Passant    schedule 29.07.2012
comment
Спасибо, я пересмотрел свой вопрос - person Paul; 31.07.2012