Быстрее (небезопасно) 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
(я не уверен, что это будет).