Что-то слабо гуглится. Все, что нагулилось - в разбросе от 80 КБ до 2 МБ.
Кто-нибудь уже решал подобный вопрос? Что выбрать, если времени на тестирование нет? Или на что надо посмотреть перед копированием?

И еще. Подумал, что надо бы создать пару-тройку потоков, чтобы стояли в очереди с уже прочитанными данными и ждали, пока первый поток не запишет свои. Разумно?

Речь идет о копировании файлов по 50 - 300 МБ количеством от 10 до 100. Цель - максимальная скорость.

Dima T Поток сознания какой-то . Ты подумал так и так, сделал выводы, выжимки из них привел, ... а мы тут при чем?

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

Ну может быть. Выходные все-таки.

Основной вопрос по размеру блоков. Какими блоками лучше копировать?

По потокам: понятно, что писать надо одним потоком. Я подумал, не попытаться ли сделать упреждающее чтение с помощью потоков. Наверное, его можно и по-другому сделать.
Зачем это делать: если блоки будут достаточно большими и делать все последовательно, то сразу после записи очередного блока будет возникать потеря времени на чтение следующего блока.

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

maytonFlying-homeЧто-то слабо гуглится. Все, что нагулилось - в разбросе от 80 КБ до 2 МБ.
Кто-нибудь уже решал подобный вопрос? Что выбрать, если времени на тестирование нет? Или на что надо посмотреть перед копированием?

И еще. Подумал, что надо бы создать пару-тройку потоков, чтобы стояли в очереди с уже прочитанными данными и ждали, пока первый поток не запишет свои. Разумно?

Речь идет о копировании файлов по 50 - 300 МБ количеством от 10 до 100. Цель - максимальная скорость.
Технологии меняются. И то что мы знали о флешках лет 10 назад сегодня может быть уже не совсем актуально.

По теме несколько мыслей.

1) Посмотри как ты ее форматируешь. extFS? NTFS? Можно попробовать варианты.
Для россыпи мелких файлов - можно попробовать сархивировать 7zip-ом
без сжатия и просто указать destination а флешку. Или TAR-ом.

2) Посмотри https://en.wikipedia.org/wiki/Flash_file_system может какие-то мысли будут.

3) Посмотри как ты ее включаешь? USB2.0 и USB3.0 это разные стандарты скоростей. Для тройки слот покрашен в синий.

4) Посмотри ... в магазинах комп-техники обычно пишут класс памяти. Ну.. для SD точно пишут. Обычно этот
класс и определяет предельную скорость. Если ты уперся в него то уже никакие многопоточки не помогу.
Не, нужно решение под "просто какую-то флэшку".
То есть, сделать программную оптимизацию под неизвестно что. Неизвестно, что будет за комп, будет ли у него USB 3.0, неизвестно, что будет за ось, неизвестно, что будет за флэшка.
Все, на чем можно сыграть - то, с чего я начал топик. Размер блока и упреждающее чтение.
А комп может оказаться и хрюшей с 512 МБ, и десятка с 16 ГБ оперативки.

В первом приближении это давно реализовано в Тотал коммандере. У него в настройках есть варианты копирования "по хорошему" и "как в проводнике".

maytonНу за 10 экспериментов с разным размером блока ты можешь найти оптимальный.

А мы тебе чем тут поможем?
А зачем форумы вообще нужны?
Любому вопрошающему можно сказать, что потрудившись и почитав справку он сам найдет нужное решение.

Может, кто-то уже решал подобную задачу?

Спасибо всем.

Я маленькие файлы пока не рассматриваю. Размер - от 50 МБ. Соответственно, и буферы рассматриваю большие (кратные 4КБ).

При копировании с одного сата-диска на другой по моей (пока недостаточной) статистике оптимальным представляется буфер 40 или 80 МБ. Может, и больше.

Думаю вот, насколько такие буферы применимы к флэшкам? Если у нее свободное пространство фрагментировано, что будет?

Dimitry SibiryakovFlying-homeЗачем это делать: если блоки будут достаточно большими и делать все последовательно, то сразу после записи очередного блока будет возникать потеря времени на чтение следующего блока.
Так это не зависит от размера блока. Используй overlapped I/O или читай и пиши разными потоками. Двух буферов по мегабайту хватит наверняка. Ну и экстремальные виды оптимизации типа FILE_FLAG_NO_BUFFERING (O_DIRECT) не забудь.
Я пока думаю о двух потоках.

maytonНу... сорцов мы не дождались. Так ште... good luck.
Дык, их еще просто нет. Я обычно сперва вопросы задаю, а потом уже что-то пишу.
ЗЫ А зачем тебе сорцы?

Dimitry SibiryakovFlying-homeПри копировании с одного сата-диска на другой по моей (пока недостаточной) статистике оптимальным представляется буфер 40 или 80 МБ.
Совершенно избыточны такие буфера. Скорость копирования перестаёт расти уже на 64 кб.
У меня на 40 МБ перестала расти. Может, у меня какой-то не общий случай, может с размерами файлов какая-то коллизия произошла, надо будет еще посмотреть.

С одной стороны, чем больше буфер, тем больше можно выиграть на "бесшовном" копировании группы файлов, с другой - в задаче файлы от 50 МБ, и если их два, то смысла в бОльших буферах действительно нет.

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

maytonFlying-homeпропущено...

Дык, их еще просто нет. Я обычно сперва вопросы задаю, а потом уже что-то пишу.
ЗЫ А зачем тебе сорцы?
В этом форуме обычно обсуждают предмет программирвоания. А он как ни странно
связан с сорцами. Тем более что в вашем случае мы имеем дело даже не с алгоритмом
которого здесь нет. А с кодингом под Windows.

Читайте Джефа Рихтера. У него был пример быстрого копирования.
Ну, я сейчас обдумываю именно алгоритм. Потому и зашел в общий топик. Если бы были вопросы по Дельфе, пошел бы туда.

Во стыдоба...
Перепутал все, что можно было перепутать. Большее с меньшим, размеры буфера...
Праздники удались.