Есть ли более быстрый способ скопировать файл, отличный от File.Copy

Требуется около 2 минут, чтобы сделать File.Copy(src, dest); для 1,6 ГБ файла из папки A в папку B на том же диске. Есть ли более быстрый способ сделать это в С#/.NET в коде (без оборудования) - Что-то с потоком, потоками и т.д.?

Будет ли поток быстрее? Как насчет класса, который разбивает файл с помощью threadpool и читает диапазон байтов/записывает диапазон байтов [это звучит как отличный способ испортить файл, но целостность здесь не является приоритетом 1, его скорость:-) ]

Я искал, но все говорят, что используют File.Copy, но он медленный (так же медленно, как и Windows Copy). Я бы предпочел не использовать сторонний инструмент.

Вот некоторые ответы на некоторые из вопросов:

Сравнение времени копирования:

> C# : 2.15m  
> Windows Explorer: 2.53m  
> TeraCopy: 2.26m
> FastCopy: 2.24m

Хорошо, это не средние значения, и я знаю, что они могут немного измениться при последующих запусках, но я действительно думал, что будет более быстрый способ скопировать файл, поскольку я предположил, что Windows выполняет дополнительные проверки безопасности и целостности: - (

Я все еще надеюсь на какой-то хороший ответ (например, "о, да, файлы более 1,5 ГБ будут быстрее, если вы сделаете буфер m и отключите безопасность n" ) - хорошо, я просто желаю в этот момент.

Ответ 1

Если вы заинтересованы в создании символической или жесткой ссылки вместо фактической копии, тогда могут оказаться полезными следующие API Windows.

Ответ 2

Вы можете попробовать использовать уже имеющееся у вас оборудование и выделить большой буфер в памяти. При чтении и записи в больших кусках вы можете удалить некоторые из служебных данных.

Однако для избавления от этого не так много накладных расходов, шея бутылки по-прежнему является дисковым вводом-выводом. В лучшем случае я ожидал бы что-то вроде 5% -ного сокращения времени выполнения.

Ответ 3

File.Copy вызывает вызов CreateFile в Kernel32.dll. Если вы копировали много и много крошечных файлов (думаю, миллионы), было бы полезно сделать P/Invoke для воспроизведения с параметрами и пропустить Разрешения. Один большой файл 99,999% из 2 минут проводится внутри кода драйвера.

Ответ 4

Я бы предположил, что windows copy, file.copy, Copyfile All используют одни и те же вызовы операционной системы для копирования. Я бы сомневался, что все, что вы пишете, превзойдет внутренние вызовы ОС.

Ответ 5

Я не пробовал это, но это может быть быстро.

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

Ответ 6

Для одного файла, идущего на один и тот же диск, ответ на ваш вопрос: нет.

Для сетевых передач, перемещения тонны файлов и других более сложных сценариев может быть место для улучшения.

Если текущее требование состоит в том, чтобы скопировать GB на второе физическое (несимвольное) местоположение на том же диске, то ваш лучший шанс для повышения производительности - скорее быстрый диск.

Ответ 7

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

Возможно, ваш диск прост и медленный, и вы достигаете максимальной производительности. В этом случае решение простое, вам нужно купить новый, или лучше два, и создать RAID 0.

Вы также можете проверить, не используется ли при копировании что-то еще не на том же диске, например, служба антивируса или индексации.

Я не предлагал никакого программного решения, потому что я не верю, что есть что-то быстрее, чем функции, предоставляемые ОС.

Ответ 8

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

Самый явный результат - повторить тест несколько раз.