Производительность чтения двоичных файлов .NET

Question

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

Кадры в настоящее время читаются таким образом, и я подозреваю, что это самый большой виновник:

private byte[] frameBuf;  
BinaryReader binRead = new BinaryReader(FS);

// Initialize a new buffer of sizeof(frame)  
frameBuf = new byte[VARIABLE_BUFFER_SIZE];  
//Read sizeof(frame) bytes from the file  
frameBuf = binRead.ReadBytes(VARIABLE_BUFFER_SIZE); 

Будет ли большая разница в .NET для реорганизацииВвод / вывод, чтобы избежать создания всех этих новых байтовых массивов с каждым кадром?

Мое понимание механизма распределения памяти в .NET слабое, поскольку я исходил из чистого фона C / C ++.Моя идея состоит в том, чтобы переписать это, чтобы разделить класс статического буфера, который содержит очень большой общий буфер с целочисленным отслеживанием фактического размера кадра, но мне нравится простота и удобочитаемость текущей реализации, и я предпочел бы сохранить его, еслиCLR уже обрабатывает это каким-то образом, о котором я не знаю.

Любой вклад будет высоко ценится.

Answer 1

Вам не нужно инициализировать frameBuf, если вы используете binRead.ReadBytes - вы получите новый байтовый массив, который перезапишет только что созданный вами. Это создает новый массив для каждого чтения, хотя.

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

Answer 2

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

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

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

Это редко воспроизводится в реальном использовании.Данные еще не будут в кеше, теперь вялый дисковод должен искать данные (много миллисекунд) и считывать их с диска (в лучшем случае, пару десятков мегабайт в секунду).Чтение данных теперь занимает добрые три из четырех величин времени дольше.Если вам удалось сделать шаг обработки вдвое быстрее, ваша программа будет работать только на 0,05% быстрее.Дай или возьми.