Который быстрее в памяти, ints или символах? И отображение файла или чтение блока?

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

Да, доступ к памяти с 4-байтовой (или даже 8-байтовой) степенью детализации выполняется быстрее, чем доступ к ней побайтно. Опять же, это компромисс - в зависимости от того, что вам нужно делать с данными впоследствии и насколько вы опытны в работе с битами в int, в целом это может быть не быстрее.

Что касается всего, что касается оптимизации:

1. мера
2. оптимизация
3. мера

Одна вещь, которую следует учитывать в отношении файлов отображения памяти, заключается в том, что файл с размером, превышающим доступный диапазон адресов, сможет отображать только часть файла. Чтобы получить доступ к остальной части файла, необходимо, чтобы первая часть была отключена, а следующая часть была сопоставлена ​​на своем месте.

Поскольку вы декодируете потоки mpeg, вы можете использовать подход с двойной буферизацией с асинхронным чтением файлов. Это работает следующим образом:

blocksize = 65536 bytes (or whatever)
currentblock = new byte [blocksize]
nextblock = new byte [blocksize]
read currentblock
while processing
   asynchronously read nextblock
   parse currentblock
   wait for asynchronous read to complete
   swap nextblock and currentblock
endwhile

Файлы с отображением в память обычно являются самыми быстрыми операциями из доступных, если вам требуется, чтобы ваш файл был доступен синхронно. (Есть некоторые асинхронные API-интерфейсы, которые позволяют O / S иногда переупорядочивать вещи для небольшого увеличения скорости, но это звучит так, как будто это бесполезно для вашего приложения)

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

Что касается обращения к памяти, в памяти x86 будет читаться целая строка за раз, независимо от того, с чем вы на самом деле работаете. Дополнительное время, связанное с небайтовыми гранулированными операциями, относится к тому факту, что целые числа не нужно выравнивать по байтам. Например, выполнение ADD займет больше времени, если что-то не выровнено по 4-байтовой границе, но для чего-то вроде копии в памяти будет небольшая разница. Если вы работаете с символьными данными, то будет быстрее сохранить их таким образом, чем читать все как целые числа и сдвигать биты.

Если вы выполняете кодирование h.264 или MPEG2, узким местом, вероятно, будет процессорное время, а не дисковый ввод-вывод в любом случае.

Что касается наилучшего размера для чтения из памяти, я уверен, вам понравится этот пост о производительности доступа к памяти и кеш-памяти. эффекты.

Это последовательные потоки битов - вы в основном потребляете их по одному биту за раз без произвольный доступ.

В этом сценарии вам не нужно прилагать много усилий для явной буферизации операций чтения и тому подобного: операционная система все равно буферизует их за вас. Раньше я писал парсеры H.264, и время полностью зависит от декодирования и манипуляции, а не от ввода-вывода.

Я рекомендую использовать стандартную библиотеку для анализа этих битовых потоков.

Flavor является таким парсером, и на веб-сайте даже есть примеры MPEG-2 (PS) и различных частей H.264, таких как M-Coder. Flavor создает собственный код синтаксического анализа на языке, подобном C ++; вот цитата из спецификации MPEG-2 PS:

class TargetBackgroundGridDescriptor extends BaseProgramDescriptor : unsigned int(8) tag = 7 
{
    unsigned int(14) horizontal_size;
    unsigned int(14) vertical_size;
    unsigned int(4) aspect_ratio_information;
}

class VideoWindowDescriptor extends BaseProgramDescriptor : unsigned int(8) tag = 8 
{
    unsigned int(14) horizontal_offset;
    unsigned int(14) vertical_offset;
    unsigned int(4) window_priority;
}