непостижимое время используется в использовании файла с отображенной памятью

Интересно, ведет ли себя mmap странно, когда размер сегмента не является четным числом страниц? Может быть, вы можете попробовать обработать последние части файла, постепенно уменьшая вдвое размеры ваших сегментов до тех пор, пока не достигнете размера, который меньше mapped_file_source :: alignment (), и обработать этот последний небольшой бит специально. делая блоки по 512 МБ, но ваш код устанавливает размер 8 << 10. Затем он умножает это на mapped_file_source :: alignment (). Действительно ли mapped_file_source :: alignment () 65536?

Я бы порекомендовал для большей переносимости и уменьшения путаницы просто использовать размер, указанный в параметре шаблона, и просто потребовать, чтобы он был кратен mapped_file_source: : alignment () в вашем коде. Или пусть люди передают степень двойки, чтобы начать с размера блока, или что-то в этом роде.

Насколько фрагментирован файл, с которым вы сравниваете? Вы можете использовать FSCTL_GET_RETRIEVAL_POINTERS , чтобы получить диапазоны, которым файл сопоставляется на диске. Я подозреваю, что последние 25 МБ будут иметь множество небольших диапазонов, чтобы учесть измеренную вами производительность.

Такое поведение выглядит довольно нелогичным. Интересно, что будет, если мы попробуем что-нибудь глупое. Если общий размер файла превышает 512 МБ, вы можете снова сравнить полные 512 МБ для последней части вместо оставшегося размера.

что-то вроде:

        if(remainder > 0)
        {
            cout << "segment size = " 
                 << remainder 
                 << " bytes for the remaining round";
                if (size > segment_size){
                    block_size = segment_size;
                    offset = size - segment_size;
                }
                else{
                    block_size = remainder;
                    offset = segment_size * i
                }
            if(!segment_compare(block_size, offset)) return false;    
        }   

Это кажется действительно глупым, потому что мы будем сравнивать часть файл два раза , но если ваши данные профилирования точны, он должен быть быстрее.

Он не даст нам ответа (пока), но если он действительно быстрее, это означает, что ответ, который мы ищем, ложь в том, что ваша программа делает с небольшими блоками данных.

Я знаю, что это не так точный ответ на ваш вопрос; но пробовали ли вы обойти всю проблему - т.е. просто сопоставить весь файл за один раз?

Я мало знаю об управлении памятью Win32; но в Linux вы можете использовать флаг MAP_NORESERVE с mmap () , поэтому вам не нужно резервировать ОЗУ для всего файла. Учитывая, что вы просто читаете оба файла, ОС должна иметь возможность выбросить страницы в любое время, если ей не хватает ОЗУ ...

Может быть, антивирусный сканер вызывает такие странные результаты? Вы пробовали без антивирусного сканера?

С уважением,

Себастьян

I would try it on a Linux or BSD just to see how it acts, out of curiousity.

I have a really rough guess about the problem: Бьюсь об заклад, что Windows выполняет множество дополнительных проверок, чтобы убедиться, что не отображается конец файла. В прошлом в некоторых ОС возникали проблемы с безопасностью, которые позволяли пользователю mmap просматривать личные данные файловой системы или данные из других файлов в области сразу за концом карты, поэтому осторожность здесь - хорошая идея для разработчика ОС. . Таким образом, Windows может использовать гораздо более осторожный метод «копирование данных с диска в ядро, обнуление несопоставленных данных, копирование данных для пользователя» вместо гораздо более быстрого «копирования данных с диска на пользователя».

Попробуйте сопоставить данные сразу под конец файла, за исключением последних байтов, которые не помещаются в блок размером 64 КБ.