mmap() для больших файлов ввода/вывода?

Я создаю утилиту на C++ для работы в Linux, которая может конвертировать видео в проприетарный формат. Видеокадры очень большие (до 16 мегапикселей), и нам нужно иметь возможность напрямую обращаться к точным номерам кадров, поэтому в нашем формате файлов используется libz для сжатия каждого кадра по отдельности и добавления сжатых данных в файл. После того как все кадры будут записаны, журнал, который включает метаданные для каждого кадра (включая их смещения и размеры файлов), записывается в конец файла.mmap() для больших файлов ввода/вывода?

В настоящее время я использую ifstream и поток, чтобы делать файл ввода/вывода, но я стараюсь оптимизировать как можно больше. Я слышал, что mmap() может увеличить производительность во многих случаях, и мне интересно, является ли мой из них одним из них. Наши файлы будут от десятков до сотен гигабайт, и хотя запись всегда будет выполняться последовательно, чтение в режиме произвольного доступа должно выполняться в постоянное время. Любые мысли о том, следует ли мне расследовать это дальше, и если да, то есть ли у кого-нибудь какие-то подсказки о том, что нужно искать?

Спасибо!

источник

2010-04-20 rcv

Насколько случайны считывания? Является ли диапазон неограниченным или ограниченным? – MSN

Чтения на самом деле не слишком случайны, так как обычное использование приведет к тому, что пользователь ищет конкретный кадр, а затем играет довольно много в последовательности. Извините - не уверен, что вы имеете в виду о диапазоне? – rcv

На боковой ноте - это не похоже на хороший способ хранения видео - даже если вам нужно качество без потерь. – slacker

На 32-битной машине ваш процесс ограничен 2-3 ГБ адресного пространства пользователя. Это означает, что (позволяя использовать другую память) вы не сможете отображать более ~ 1 ГБ вашего файла за раз. Это NOT означает, что вы не можете использовать mmap() для очень больших файлов - просто вам нужно отображать только часть файла за раз.

Это, как говорится, mmap() все еще может быть большой победой для больших файлов. Самое существенное преимущество заключается в том, что вы не теряете память для хранения данных TWICE - одна копия в системном кеше, одна копия в приватном буфере приложения - и время процессора для создания этих копий. Это может быть еще более важным ускорением для случайного доступа, но «случайная» часть должна быть ограничена в диапазоне до вашего текущего сопоставления.

источник

2010-04-20 23:57:36 slacker

Правильно, подход, о котором я думал, был в mmap настолько большим, насколько позволяет архитектура, когда пользователь читает фрейм, а затем просто читает с этой карты так долго, как мне нужны данные. Кто-нибудь знает, как накладные расходы вызова mmap() сравниваются с seek()? – rcv

@Boatzart: Они сопоставимы. Основная стоимость здесь - вызов ядра и отображение, выполняемое ядром. Но это STILL нужно сделать для 'seek()'. – slacker

Я предлагаю отображать меньшие части файла за раз - чтобы вы не тратили слишком много памяти и адресного пространства. Накладные расходы на вызов 'mmap()' пренебрежимо малы по сравнению с временем, необходимым для обработки данных порядка мегабайт. – slacker

Если ваши файлы имеют размер 10 ГБ или более, тогда даже не думайте о том, чтобы попытаться использовать mmap() в 32-битной архитектуре. Перейдите непосредственно к 64-битной ОС, которая должна иметь возможность обрабатывать ее просто отлично.

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

источник

2010-04-20 23:55:33

mmap() для больших файлов ввода/вывода?

ответ

Смежные вопросы