Сравниваю производительность FILE (fwrite) и аналога для MMap.
Начну сразу с результатов.
FILE работает стабильно быстрее, не сжирает оперативку, сжирает весь кеш.
MM работает произвольно (т.е. один запуск может дать время x, запуск через некоторое время может дать время 2*x), сжирает весь кэш, если в ручную не делать flush, так же сжирает все оперативку под ноль, система аж загибается.
В тесте, произвожу запись n-го числа записей. Общий размер получаемого файла ~3GB. Время замеряю через
| Код |
clock_t start_load = clock();
// do
cout << " --> result time: " << (clock() - start_get)/CLOCKS_PER_SEC << endl;
|
Делаю запуски отдельно для FILE отдельно для MM с временным интервалом, на передышку железу.
Испытуемые функции
| Код |
void write_f(const string& msg, size_t count)
{
remove("file");
cout << "Start test fwite\n";
clock_t start = clock();
FILE *file = fopen("file", "w+");
for(int i = 0; i < count; i++)
fwrite(msg.c_str(), 1, msg.size(), file);
fclose(file);
cout << "result time: " << (clock() - start)/CLOCKS_PER_SEC << endl;
}
void write_mm(const string& msg, size_t count)
{
remove("file");
FILE *file = fopen("file", "w+");
fclose(file);
cout << "Start test mm wite\n";
clock_t start = clock();
{
file_mapping file1("file", mode_t::read_write);
MMFile file(&file1, 1);
for(int i = 0; i < count; i++)
file.write(msg.c_str(), msg.size());
}
cout << "result time: " << (clock() - start)/CLOCKS_PER_SEC << endl;
}
|
Реализация MM используется бустовская, из за кроссплатформенности.
MMFile, имплементация, над file_mapping и region_mapped.
Функция write()
| Код |
size_t MMFile::write( char const* buf, size_t size )
{
Offset tell_size = static_cast<offset_t>(tell() + size);
size_t retWtire = size;
if(tell_size > fileSize_ )
{
truncate(tell_size);
}
char const* end = buf + size;
char* windowEnd = reinterpret_cast<char *>( region_.get_address() ) + windowSize_;
for( ;; )
{
if( size <= bytesLeft_ )
{
memcpy( windowEnd - bytesLeft_, end - size, size );
bytesLeft_ -= size;
break;
}
else
{
memcpy( windowEnd - bytesLeft_, end - size, bytesLeft_ );
size -= bytesLeft_;
bytesLeft_ = windowSize_;
if(flushPage_++ > 10)
{
region_.flush();
flushPage_ = 0;
}
region_ = mapped_region( file_, read_write, region_.get_offset() + windowSize_, windowSize_ );
windowEnd = reinterpret_cast<char *>( region_.get_address() ) + windowSize_;
}
}
return retWtire;
}
|
Код
| Код |
if(flushPage_++ > 10)
{
region_.flush();
flushPage_ = 0;
}
|
вставлен для избежания сжирания всей оперативки. Иначе это происходит.
Собстно, проблема именно в том почему 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 то это происходит только при сжиранию всей оперативки, что приводит к временному зависанию системы. Такой вариант совсем неудовлетворительный. |
)
