Проецируемые на память файлы , быстродействие и т.д.

[LuckLess]

Цитата leo @ 29.06.06, 07:02

Интересно, почему ты при создании dst не задаешь flags как в src ?

А зачем? Ну поставлю теже флаги и на dst днем...

[Ace]

Цитата leo @ 29.06.06, 07:02

Просто копировать файлы (без модификации) с помошью MMF это нечто выдающееся, разве что "поиграться"

Для этого и давалось.

Цитата leo @ 29.06.06, 07:02

В приведенном коде лучше закомментировать FlushView и посмотреть, что будет с системой при копировании файла, превышающего размер ОЗУ. Тут даже точные измерения не нужны - достаточно включить системный монитор и понаблюдать за доступной памятью, обменом страниц и записью на диск. Ну и затем посмотреть как будет вести себя система после такого стресса - пооткрывать папки, программы, документы.

Чудес не бывает, поэтому и реальная запись на диск будет производится тогда, когда системе будет выгодно это сделать. Со всеми вытикающими занятиями ресурсов для этой операции.

Цитата leo @ 29.06.06, 07:02

PS: Да, кстати, ты просил привести хоть один официальный источник, пиарящий чудесный супербыстрый MMF. Загляни в MSDN: Platform SDK разделы File Mapping и Improving Application Performance, выпиши на бумажку и заучи фразы: "Adwantages of File Mapping", "major adwantages", "Faster and easier file access", "access files more quickly and easily", "improves efficiency", "improve general system performance" (и это как раз в отношении отложенной записи !), ну и наконец откровенное лукавство "Using memory-mapped files for sequential file access is faster than standard sequential file access".

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

ЗЫ. На "грязное" обращение лень отвечать, это можешь и без меня делать, перед зеркалом...

[LuckLess]

Указал флаг и для hWiler .. скорость поднялась еще на 10-12% .. вечером выложу все результаты.. и для mmap тоже..

[UncleBob]

LuckLess, у меня твоя прожка выдает следующие результаты (после правки флагов для hFilew). Ну и я переставил порядок тестов по нарастающей размера буфера.

4KB  NB 100.5
32KB NB 49.344
64KB NB 42.688
4MB  NB 38.109
32MB NB 31.953
32MB B 93.672

Samsung SP2004C (SATA2), партиция NTFS. Файл 687Мб.

Так что...

[LuckLess]

Цитата Uncle_Bob @ 29.06.06, 10:05

Samsung SP2004C (SATA2), партиция NTFS. Файл 687Мб.

Так что...

Почто идентичный результат (учитывая что у меня САТА2 рейд .. поэтому побустрее..)
да, чем больше буффер, тем быстрее.
Буфферизация дает страаашный тормоз(особенно буферизация файла - который копируем).

[UncleBob]

LuckLess,

ну на самом деле FILE_FLAG_SEQUENTIAL_SCAN не так и портит картину...

4KB  B  49.219
4KB  NB 97.984
 
32KB B  56.438
32KB NB 50
 
64KB B  41.016
64KB NB 41.484
 
4MB  B  161.578
4MB  NB 38.422
 
32MB B  102.016
32MB NB 32.469
 
64MB B  56.422
64MB NB 0.046 // не катит

[LuckLess]

Цитата Uncle_Bob @ 29.06.06, 10:48

4KB B 49.219
4KB NB 97.984

32KB B 56.438
32KB NB 50

64KB B 41.016
64KB NB 41.484

4MB B 161.578 // Очень странная цифра
4MB NB 38.422

32MB B 102.016 // Очень странная цифра
32MB NB 32.469

64MB B 56.422
64MB NB 0.046 // не катит

Гм. Для больших буфферов FILE_FLAG_SEQUENTIAL_SCAN что, - замедляет?

[UncleBob]

Цитата LuckLess @ 29.06.06, 10:57

Гм. Для больших буфферов FILE_FLAG_SEQUENTIAL_SCAN что, - замедляет?

Попробуй у себя.

[leo]

Да нет, я думаю все в пределах допустимой погрешности, т.к. на больших файлах FILE_FLAG_SEQUENTIAL_SCAN практически не должен влиять на результаты. Если верить MSDN и статейкам, то этот флаг - является лишь хинтом-подсказкой для ОС на начальном этапе чтения\записи, а затем она сама распознает последовательный доступ, если даже этот флаг не был установлен

Сообщение отредактировано: leo - 29.06.06, 15:38

[LuckLess]

Цитата Uncle_Bob @ 29.06.06, 11:36

Попробуй у себя.

   std::cout << "4KB NB " <<  RWNBCopy ("E:\\file.avi", "E:\\file2.avi", 4*1024) << "\n"; //46
   std::cout << "4KB NB SS " <<  RWNBCopy ("E:\\file.avi", "E:\\file2.avi", 4*1024,FILE_FLAG_SEQUENTIAL_SCAN) << "\n"; //22.5
   std::cout << "32MB NB " <<  RWNBCopy ("E:\\file.avi", "E:\\file2.avi", 32*1024*1024) << "\n"; //18
   std::cout << "32MB NB SS " <<  RWNBCopy ("E:\\file.avi", "E:\\file2.avi", 32*1024*1024,FILE_FLAG_SEQUENTIAL_SCAN) << "\n"; //36

[leo]

LuckLess
Задавая FILE_FLAG_SEQUENTIAL_SCAN, ты отключаешь NO_BUFFERING и результаты получаются примерно такие же как для flags = 0

[LuckLess]

Цитата leo @ 30.06.06, 07:39

LuckLess
Задавая FILE_FLAG_SEQUENTIAL_SCAN, ты отключаешь NO_BUFFERING и результаты получаются примерно такие же как для flags = 0

std::cout << "4KB NB SS " << RWNBCopy ("E:\\file.avi", "E:\\file2.avi", 4*1024,FILE_FLAG_SEQUENTIAL_SCAN) << "\n"; //22.5
Фигасе - такиеже..

Добавлено 30.06.06, 07:41
такое ощущение, что FILE_FLAG_SEQUENTIAL_SCAN оптимизирует систему для работы с малыми буфферами..

[leo]

LuckLess
Я не понял с чем ты сравниваешь. Чего-то я твоих данных для 4К и flags = 0 вроде не видел. А что касается NO_BUF, так он и должен быть хуже при малых размерах буфера.
Сделай в одном проходе чередование flags = 0 и SEQUENTIAL при 4К, тогда будет видна разница и разброс

[leo]

МОДЕРАТОРАМ
На мой взгляд, название темы выбрано неудачно.
Речь идет конкретно о копировании файлов, и MMF здесь выступает лишь как один из методов, наряду с обычными Read\WriteFile. Заостряя внимание на MMF мы опять негласно расширяем тему дискуссии, что может опять увести разговор в сторону голословных рассуждений и споров. Поэтому думаю лучше изменить название темы на прежнее или еще более конкретное, типа "Как быстрее копировать файлы" или т.п.

[LuckLess]

FILE_FLAG_SEQUENTIAL_SCAN дает прирост 11-13% на 4кб буффере в сравнении с просто копировании без флагов.