Сравниваю производительность FILE (fwrite) и аналога для MMap.

Начну сразу с результатов. 
FILE работает стабильно быстрее, не сжирает оперативку, сжирает весь кеш.
MM работает произвольно (т.е. один запуск может дать время x, запуск через некоторое время может дать время 2*x), сжирает весь кэш, если в ручную не делать flush, так же сжирает все оперативку под ноль, система аж загибается.


В тесте, произвожу запись n-го числа записей. Общий размер получаемого файла ~3GB. Время замеряю через 


Делаю запуски отдельно для FILE отдельно для MM с временным интервалом, на передышку железу.
Испытуемые функции


Реализация MM используется бустовская, из за кроссплатформенности.

MMFile, имплементация, над file_mapping и region_mapped.
Функция write()


Код

вставлен для избежания сжирания всей оперативки. Иначе это происходит.

Собстно, проблема именно в том почему MM работает медленнее, когда все бьют в грудь что мол работает быстрее и лучше.


Как это вижу я:
В случаем с MM:
при маппинге очередного региона, он считывается из диска в кеш, после чего отображается в пространство пользователя (т.е. не происходит копирования). При большом числе итераций записи, кеш забивается новыми страницами, которые так же быстро отображаюсться в пространство процесса, из за чего тот сжирает всю оперативку, так как flush не происходит при достигании какого то лимита, я происходит когданибудь потом. Как правило когда оперативка и кешь весь сожран и деваться уже некуда, и тут начинаются тормоза. Которые и сводят на 0 все эти плюшки с отображением.

-------------------------------------------------------------------------
Маппим ровно по page_size.



Измененные условия теста:
Маппим по 10 * page_size, делаешм flush перед каждый новым маппингом, получаем время работы x (примерно равное fwrite)
Маппим по 10 * page_size, делаешм flush на каждый 10 маппинг, получаем время работы 2.3 * x 

Маппим по 10 * page_size, не делаешм flush, получаем время работы x/3. размер файла примерно равен размеру свободной оперативки. После система на некоторое время подвисла.

Сохраню поста, и попробую с файлом большем чем размер оперативки.

Добавлено через 14 минут и 34 секунды
В общем если не делать flush то это происходит только при сжиранию всей оперативки, что приводит к временному зависанию системы. Такой вариант совсем неудовлетворительный.

если делать flush в ручную, то в лучшем случае время работы такое же как у fwrite, в худшем на 30% дольше.

На основе чего напрашивается вывод, для для логики, когда требуется постоянная запись в файл и соответственно его увеличение, MM не лучший вариант :(
Думаю для логики когда надо прочитать весь файл небольшими кусочками это тоже не даст прироста, собственно как и при доступе к произвольной позиции.

Скорость чтения через read сложно довести до скорости чтения через mmap. То есть теоретически ее можно подогна вплотную, но код получится очень системозависимым, тут плясать нужно не столько в сторону page_size, сколько в размер кешей процессора. В общем эксперементальным путем мне удавалось практически сравнять скорости, но это был метод тыка. mmap это делает сам.

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

ПС. ОС, архитектура какие?

ОС кросcплатформенность, x32/x64.

Если сравнивать только операции write и memcpy (в случае mm), с файлом заданного размера, и если мапим весь файл сразу, то да прирост в 10 раз. Только вот на сколько такой тест верен? Ведь, если файл будет большой (для чего собсно mm и используется) то придется городить огороды с маппингом по частям, что все равно приведет к сжиранию всей оперативки под ноль и временному отказу систему (пока ОС не сбросит буфера на диск). А еще и размер файла далеко не константный и заранее не известный и он растет по мере появления данных, следовательно постоянные truncat, и опять таки (в зависимости от скорости пробега по файлу) сжирание всей оперативки.

А причем тут шедулер ?

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

То есть ты проводил одинаковые тесты на нескольких платформах?

1. Фактическая запись файла на диск через mmap не может быть быстрее в 10 раз записи через write. Скорее всего ты увидел работу кешей, т.е. write пишет прямо сейчас, а mmap бросила в буфер, а когда уж оно там реально запишется - не ее дело. Я знаю, что при записи через write тоже используется буферизация.

2. mmap в первую очередь предоставляет удобство программисту, и она не виновата, что он пытается использовать ее несколько не по назначению.

У тебя система колом встает при свопинге! Настрока более агрессивной политики сброса ненужных данных на диск должна помочь. Ну а шедулер именно процессов тут и правда ни при чем.

ПС. Весь цимес в пункте 2.

А если не сразу - то нужно 10 раз прежде подумать, нужен ли тут mmap   
Постоянные изменения мэпинга могут запросто быть более накладными, чем 10 прямых записей в параллель   

ну по сути подтвердили мои предположения.

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

cupper, имхо, mmap удобней тогда, когда ты работаешь с большим (не огромным!) файлом фиксированной длины.  Причем функции обработки данных умеют работать только с памятью. Или они выполняют случайный доступ к случайных ячейкам.
В остальных случаях, имхо, проще работать с файлом напрямую.

Ещё mmap можно использовать для общего доступа к памяти двух программ, в Linux физический файл на диске можно не создавать, в Windows наверно тоже - в этом случае mmap действительно будет работать быстрее.