Сорри за задержку ответа.

Dima TpetravБыла задача чтения текстового файла на несколько гигабайт. Просто таблица с данными — потом данные отправлялись на обработку. Читался этот файл с помощью обычного fscanf(). Автору программы показалось, что его приложение тормозит именно из-за операций чтения из файла. :) В общем, я разобрался с меппингом файлов и программу перевели на sscanf(). Я не верил в какое-то ускорение, а даже предполагал замедление программы.

Случилось ужасное. Производительность приложения на маппинге упала в сотни раз (или даже в тысячи, точно не помню)....
мап тут вообще ни при чем, у тебя главный тормоз scanf`ы. Надо было писать свой парсер строки заточенный под твою строку. В идеале разбор строки в один проход. Дальше без разницы: читать кусок файла в буфер, парсить, читать следующий кусок и т.д. или сделать мап и обработать как один большой кусок.
Вариант с мап просто удобнее, т.к. код меньше и проще. В случае с буфером надо попутно решать проблемы контроля вся ли строка в буфере, докачка в буфер с учетом этого и т.п. В принципе несложно, но с мап этого вообще не надо.

Дальше от непонимания сути рождаются домыслы из серии "мап - магическая штука :)"
LOL, Dima T , спасибо за разъяснения очевидных вещей. Конечно, дело в sscanf. Это был пример совершенно неожиданных проблем с маппингом при применении обычных приёмов программирования. А жизнь так складывается (у меня), что он не очень то и нужен. Если бы маппинг так просто и давал ускорение почти везде, то все только им бы и пользовались.

Dima TpetravНу хорошо. Предположим, что в данном алгоритме при меппинге ОС так разрулила контроллером диска, что данные никогда не проходили через интерфейсную шину диска, данные никогда не были в оперативной памяти и контроллер сам внутри винчестера всё скопировал. И в этом и результат такой впечатляющий.

Мне почему-то кажется, что используя меппинг мы отказываемся от кеширующего механизма ОС. Что в 99.9% случаев приведёт к кардинальному замедлению программ. И при меппинге нужно подключать специалиста и чётко обосновывать зачем и как мы это делаем. И самим реализовывать кеширование. Возможно я не прав.
ХЗ что ответить на этот поток сознания :)

Напишу как я понимаю работу виндовса с файлами: при любом доступе к файлу (копирование, чтение, мап) данные из файла попадают в кэш ОС, а дальше при повторном чтении (неважно fread() или мап) берутся уже из кэша. При записи сначала пишется в кеш, затем из кэша на диск (в файл).

Теперь рассмотрим детально что происходит на примере изменения 1 байта в файле:
1. Мап. Замапили файл, обращаемся в этому байту, происходит чтение 4 кб (страницы памяти) в кэш, т.е. получаем страницу физической памяти ассоциированную с куском файла, дальше эта физическая страница подставляется в адресное пространство моего процесса, т.е. фактически я меняю сразу в кэше ОС. Дальше менеджер памяти скидывает из кэша на диск.
2. fread(1 байт) происходит чтение 4 кб (страницы памяти) в кэш (как в п.1), оттуда байт копируется в память моего процесса, затем там его меняю, fwrite(1 байт) - ОС копирует из моей памяти в ту самую страницу кэша. Дальше как в п.1

Никакой мистики и магии. Мап быстрее за счет того что нет этих лишних копирований в памяти. Работа напрямую с кэшем ОС. И плюс накладные расходы на вызов fread()/fseek()/fwrite() в цикле.
А ничего, что копирование в памяти занимает пренебрежимо малое время по сравнению с файловым вводом/выводом? И это малое время дало маппингу ускорение в разы?

И читаешь ты не по одному байту, а в основном 1*bufSize байт, блин.

PS: Попробуй плиз свою программу с меппингом запустить с флешки. Или с сетевого диска.