Самый быстрый способ чтения файла в Linux?

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

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


person mezamorphic    schedule 16.10.2013    source источник
comment
boost::iostreams использует mmap в Linux, вы можете увидеть небольшую разницу, используя его напрямую.   -  person Jesse Good    schedule 16.10.2013
comment
Возможно, вам понадобится readv(), это позволит вам собирать данные в байты массива. Подробнее см. man readv().   -  person rakib_    schedule 16.10.2013


Ответы (2)


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

Лучше всего, как всегда, тестировать и сравнивать.

person Art    schedule 16.10.2013

Не позволяйте себя одурачить такими ленивыми вещами, как картирование памяти. Лучше сосредоточьтесь на том, что вам действительно нужно. Вам действительно нужно прочитать весь файл в память? Тогда прямой способ открытия, чтения кусков в цикле и закрытия файла будет настолько быстрым, насколько это возможно.

Но часто вы действительно этого не хотите. Вместо этого вы можете захотеть прочитать определенные части, блок здесь, блок там, перейти через файл, прочитать блок в определенной позиции и т. д.

Тогда все еще fseekобработка этих позиций и freadобработка блоков не будет иметь накладных расходов, о которых стоит упомянуть. Но может быть удобнее использовать отображение памяти, чтобы позволить операционной системе или библиотеке заниматься такими вещами, как выделение памяти и т. Д. Однако это не ускорит работу.

person Alfe    schedule 16.10.2013
comment
mmap должен быть быстрее для достаточно больших файлов, потому что вы можете избежать копирования данных из кэша страниц в пользовательскую среду. Это совсем не лень. При произвольном доступе не должно быть никакой разницы, поскольку mmap на самом деле не считывает больше данных из файловой системы, чем любой случайный поиск/чтение. Единственным недостатком mmap могут быть накладные расходы на создание сопоставления, но они не должны быть выше, чем вызовет malloc. Особенно, когда вы вызываете malloc несколько раз. - person Art; 16.10.2013
comment
Ну, отображение памяти может быть реализовано лениво, конечно (зависит от операционной системы), в то время как чтение содержимого файла в блок памяти не может (или, по крайней мере, это было бы намного сложнее и, следовательно, маловероятно). Однако главный аспект моего ответа заключался в том, чтобы указать, что помещение всего файла в память, вероятно, не имеет смысла и должно быть пересмотрено. - person Alfe; 16.10.2013
comment
Что касается упомянутого преимущества предотвращения копирования данных из кеша страниц в пространство пользователя: кеширование — это совершенно другой аспект, который я не рассматривал. Это применимо только в том случае, если пользователь читает файл более одного раза; Я интерпретировал вопрос так, как будто он спрашивал, как на самом деле прочитать файл как можно быстрее (и прочитать его на самом деле). - person Alfe; 16.10.2013
comment
Нет. Чтобы избежать копирования из кеша страниц, нужно не читать его более одного раза/кешировать. Операционная система всегда будет считывать файл с диска (или из сети) в кэш страниц, если только вы не сделаете каких-то очень специфических действий (это рекомендуется только в том случае, если вы точно знаете, что делаете и почему). Таким образом, чтение содержимого файла каким-либо другим способом, кроме mmap, будет выполнять копирование из памяти в память (если только операционная система не имеет механизмов нулевого копирования, но они довольно дороги и эквивалентны mmap, за исключением того, что они медленнее и работают только тогда, когда все звезды сошлись в самый раз). - person Art; 16.10.2013
comment
@Art: Вы измерили это? Друг пытался оптимизировать **** из чтения файла целых чисел (текст, представляющий целые числа, ~ 100 МБ), разбитого на строки, и самым быстрым было чтение кусков, обработка каждой полной строки, перемещение того, что осталось необработанным, в начало блок и чтение другого фрагмента после этого... Я бы рекомендовал протестировать различные альтернативы - person David Rodríguez - dribeas; 16.10.2013
comment
Я не измерял его в этом конкретном случае, потому что на все вопросы о производительности лучше всего отвечают тесты (именно это я и рекомендую в своем ответе на этот вопрос). Что я сделал, так это работал в операционной системе на всех уровнях между MMU и системными вызовами чтения и mmap, включая замену всей системы VM и перестройку буферного кеша, поэтому я хорошо знаком с тем, как путь ввода-вывода работает. read делает почти то же самое, что и mmap, за исключением того, что read также нужно копировать данные. - person Art; 16.10.2013
comment
Интересные моменты, @Art, спасибо за информацию. Я предполагаю, что копирование в память настолько быстрее, чем чтение с диска, что эталонные тесты не заметят этого. Тем не менее ваша точка зрения заставляет меня исправиться. - person Alfe; 16.10.2013
comment
Что ж, ожидание диска обычно занимает время по настенным часам. Но если вы внимательно посмотрите профили операционных систем или даже просто обычных библиотек, то очень часто обнаружите, что копирование памяти из одного места в другое является самым большим пожирателем процессора при нормальной рабочей нагрузке. Вот почему разработчики ОС так заботятся о копировании, вот почему так много исследований было посвящено схемам нулевого копирования (к сожалению, большинство из них довольно непрактичны, и большинство вещей в конечном итоге используют или заново изобретают mmap). - person Art; 16.10.2013