Почему .NET async ждет копию файла намного больше, чем процессор, чем синхронный вызов File.Copy()?

Question

Почему код ниже результатов в:

public static class Program 
{ 
    public static void Main(params string[] args) 
    { 
     var sourceFileName = @"C:\Users\ehoua\Desktop\Stuff\800MFile.exe"; 
     var destinationFileName = sourceFileName + ".bak"; 

     FileCopyAsync(sourceFileName, destinationFileName); 

     // The line below is actually faster and a lot less CPU-consuming 
     // File.Copy(sourceFileName, destinationFileName, true); 

     Console.ReadKey(); 
    } 

    public static async void FileCopyAsync(string sourceFileName, string destinationFileName, int bufferSize = 0x1000, CancellationToken cancellationToken = default(CancellationToken)) 
    { 
     using (var sourceFile = File.OpenRead(sourceFileName)) 
     { 
      using (var destinationFile = File.OpenWrite(destinationFileName)) 
      { 
       Console.WriteLine($"Copying {sourceFileName} to {destinationFileName}..."); 
       await sourceFile.CopyToAsync(destinationFile, bufferSize, cancellationToken); 
       Console.WriteLine("Done"); 
      } 
     } 
    } 
} 

Хотя File.Copy(): https://msdn.microsoft.com/en-us/library/system.io.file.copy(v=vs.110).aspx намного меньше процессора затрат:

Так есть еще реальный интерес, использующий async/ожидание для копирования файлов?

Я думал, что сохранение потока для копирования может стоить того, но функция File.Copy windows, похоже, выиграла битву с точки зрения CPU%. Некоторые утверждают, что это из-за реальной поддержки DMA, но все же я делаю что-нибудь, чтобы испортить выступления? Или есть что-то, что можно сделать для улучшения использования ЦП с помощью метода async?

Answer 1

File.OpenRead(sourceFileName) эквивалентен new FileStream(sourceFileName, FileMode.Open, FileAccess.Read, FileShare.Read), который в свою очередь эквивалентен public FileStream(sourceFileName, FileMode.Open, FileAccess.Read, FileShare.Read, 4096, false), то есть с false для асинхронных операций ввода-вывода. Эквивалент относится к File.OpenWrite.

Как таковые, любые операции XXXAsync не будут использовать асинхронный ввод-вывод, но будут подделывать его, используя потоки потоков.

Так что он не получает ничего от асинхронного ввода-вывода и тратит по крайней мере один поток. У вас есть дополнительная блокировка потоков на вводе/выводе, чего вы хотели избежать. Обычно я ожидал, что async сам по себе будет работать немного медленнее, чем синхронизация (async обычно жертвует одноразовой скоростью для лучшей масштабируемости), но я определенно ожидаю, что это немного улучшится, если вообще произойдет, чем обернуть все это в Task.Run() ,

Я все еще не ожидал, что это будет так же плохо, но, возможно, защита от вредоносных программ вызывает беспокойство при написании .exe.

Вы бы надеялись, что лучше скопировать не-exe и с асинхронными потоками.

Answer 2

Это довольно абсурдные номера перформансов. Вы просто не измеряете то, что считаете себя. Это не должно быть больше, чем небольшая ошибка, простая копия памяти для памяти для кэшированных данных файла. Как и File.Copy(). Работает на ~ 35 гигабайт в секунду на машине с достойной памятью DDR3, поэтому не может быть больше нескольких десятков миллисекунд. Даже если файл не кэширован или на компьютере не хватает ОЗУ, вы все равно не можете получить такую ​​нагрузку на процессор, ваш код будет заблокирован в ожидании диска.

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

Простая проверка, отключение или исключение и повторная попытка.