Быстрее (небезопасно) BinaryReader в .NET

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

Следовательно, я понял, что реализация BinaryReader по умолчанию в .NET довольно медленная. Посмотрев на него с .NET Reflector Я наткнулся на это:

public virtual int ReadInt32()
{
    if (this.m_isMemoryStream)
    {
        MemoryStream stream = this.m_stream as MemoryStream;
        return stream.InternalReadInt32();
    }
    this.FillBuffer(4);
    return (((this.m_buffer[0] | (this.m_buffer[1] << 8)) | (this.m_buffer[2] << 0x10)) | (this.m_buffer[3] << 0x18));
}

Что мне кажется крайне неэффективным, думая о том, как компьютеры были разработаны для работы с 32-битными значениями, поскольку был изобретен 32-битный процессор.

Итак, я создал свой собственный (небезопасный) класс FastBinaryReader с таким кодом, как это:

public unsafe class FastBinaryReader :IDisposable
{
    private static byte[] buffer = new byte[50];
    //private Stream baseStream;

    public Stream BaseStream { get; private set; }
    public FastBinaryReader(Stream input)
    {
        BaseStream = input;
    }


    public int ReadInt32()
    {
        BaseStream.Read(buffer, 0, 4);

        fixed (byte* numRef = &(buffer[0]))
        {
            return *(((int*)numRef));
        }
    }
...
}

Это намного быстрее - мне удалось сэкономить 5-7 секунд с момента, когда потребовалось прочитать 500-мегабайтный файл MB, но он все еще довольно медленный (29 секунд и 22 секунды с моим FastBinaryReader).

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

Я также добавил ссылки ReadInt32 и т.д., и я закончил с этим кодом:

using (var br = new FastBinaryReader(new FileStream(cacheFilePath, FileMode.Open, FileAccess.Read, FileShare.Read, 0x10000, FileOptions.SequentialScan)))

  while (br.BaseStream.Position < br.BaseStream.Length)
  {
      var doc = DocumentData.Deserialize(br);
      docData[doc.InternalId] = doc;
  }
}

   public static DocumentData Deserialize(FastBinaryReader reader)
   {
       byte[] buffer = new byte[4 + 4 + 8 + 4 + 4 + 1 + 4];
       reader.BaseStream.Read(buffer, 0, buffer.Length);

       DocumentData data = new DocumentData();
       fixed (byte* numRef = &(buffer[0]))
       {
           data.InternalId = *((int*)&(numRef[0]));
           data.b = *((int*)&(numRef[4]));
           data.c = *((long*)&(numRef[8]));
           data.d = *((float*)&(numRef[16]));
           data.e = *((float*)&(numRef[20]));
           data.f = numRef[24];
           data.g = *((int*)&(numRef[25]));
       }
       return data;
   }

Любые дальнейшие идеи о том, как сделать это еще быстрее? Я думал, может быть, я мог бы использовать сортировку для отображения всего файла прямо в память поверх некоторой пользовательской структуры, поскольку данные являются линейными, фиксированными и последовательными.

SOLVED: Я пришел к выводу, что FileStream buffering/BufferedStream ошибочен. Пожалуйста, см. Принятый ответ и мой собственный ответ (с решением) ниже.

Ответ 1

Когда вы делаете filecopy, большие фрагменты данных считываются и записываются на диск.

Вы читаете весь файл по четыре байта за раз. Это должно быть медленнее. Даже если реализация потока достаточно умна для буферизации, у вас по-прежнему есть как минимум 500 MB/4 = 131072000 вызовов API.

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

Ответ 2

Я столкнулся с аналогичной проблемой производительности с BinaryReader/FileStream, и после профилирования я обнаружил, что проблема связана не с буферизацией FileStream, а с этой строкой:

while (br.BaseStream.Position < br.BaseStream.Length) {

В частности, свойство br.BaseStream.Length на FileStream делает (относительно) медленный системный вызов для получения размера файла в каждом цикле. После изменения кода на это:

long length = br.BaseStream.Length;
while (br.BaseStream.Position < length) {

и используя соответствующий размер буфера для FileStream, я добился аналогичной производительности с примером MemoryStream.

Ответ 3

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

Это заставляет меня думать, что реализация буфера FileStream (или BufferedStream в этом случае) ошибочна, потому что независимо от того, какой размер буфера я пытался, производительность все еще сосала.

  using (var br = new FileStream(cacheFilePath, FileMode.Open, FileAccess.Read, FileShare.Read, 0x10000, FileOptions.SequentialScan))
  {
      byte[] buffer = new byte[br.Length];
      br.Read(buffer, 0, buffer.Length);
      using (var memoryStream = new MemoryStream(buffer))
      {
          while (memoryStream.Position < memoryStream.Length)
          {
              var doc = DocumentData.Deserialize(memoryStream);
              docData[doc.InternalId] = doc;
          }
      }
  }

До 2-5 секунд (зависит от кэша диска, который я угадываю) теперь из 22. Который сейчас достаточно хорош.

Ответ 4

Одно предостережение; вам может потребоваться дважды проверить ваш предикат процессора... предполагая, что little-endian не совсем безопасен (подумайте: itanium и т.д.).

Вы также можете посмотреть, не имеет ли значения BufferedStream (я не уверен, что это будет).