Qual é a maneira mais rápida de criar uma soma de verificação para arquivos grandes em C #

Eu tenho que sincronizar arquivos grandes em algumas máquinas. Os arquivos podem ter até 6 GB de tamanho. A sincronização será feita manualmente a cada poucas semanas. Não posso levar o nome do arquivo em consideração porque eles podem mudar a qualquer momento.

Meu plano é criar somas de verificação no PC de destino e no PC de origem e copiar todos os arquivos com uma soma de verificação, que ainda não está no destino, para o destino. Minha primeira tentativa foi algo assim:

using System.IO;
using System.Security.Cryptography;

private static string GetChecksum(string file)
{
    using (FileStream stream = File.OpenRead(file))
    {
        SHA256Managed sha = new SHA256Managed();
        byte[] checksum = sha.ComputeHash(stream);
        return BitConverter.ToString(checksum).Replace("-", String.Empty);
    }
}

O problema era o tempo de execução:
- com SHA256 com um arquivo de 1,6 GB -> 20 minutos
- com MD5 com um arquivo de 1,6 GB -> 6,15 minutos

Existe uma maneira melhor - mais rápida - de obter a soma de verificação (talvez com uma melhor função de hash)?

O problema aqui é que SHA256Managedlê 4096 bytes de cada vez (herda FileStreame substitui Read(byte[], int, int)para ver o quanto ele lê do fluxo de arquivos), que é um buffer muito pequeno para E / S de disco.

Para acelerar as coisas (2 minutos para hash arquivo de 2 GB na minha máquina com SHA256, 1 minuto para MD5) envoltório FileStreamem BufferedStreame definir o tamanho do buffer de tamanho razoável (eu tentei com tampão de ~ 1 Mb):

// Not sure if BufferedStream should be wrapped in using block
using(var stream = new BufferedStream(File.OpenRead(filePath), 1200000))
{
    // The rest remains the same
}

Não faça a soma de verificação do arquivo inteiro, crie somas de verificação a cada 100mb, aproximadamente, para que cada arquivo tenha uma coleção de somas de verificação.

Então, ao comparar somas de verificação, você pode parar de comparar após a primeira soma de verificação diferente, sair cedo e evitar que você processe o arquivo inteiro.

Ainda levará tempo integral para arquivos idênticos.

Como Anton Gogolev observou , o FileStream lê 4096 bytes por vez por padrão, mas você pode especificar qualquer outro valor usando o construtor FileStream:

new FileStream(file, FileMode.Open, FileAccess.Read, FileShare.ReadWrite, 16 * 1024 * 1024)

Observe que Brad Abrams, da Microsoft, escreveu em 2004:

não há benefício em envolver um BufferedStream em torno de um FileStream. Copiamos a lógica de buffer do BufferedStream no FileStream cerca de 4 anos atrás para incentivar um melhor desempenho padrão

fonte

Invoque a porta do Windows do md5sum.exe . É cerca de duas vezes mais rápido que a implementação do .NET (pelo menos na minha máquina usando um arquivo de 1,2 GB)

public static string Md5SumByProcess(string file) {
    var p = new Process ();
    p.StartInfo.FileName = "md5sum.exe";
    p.StartInfo.Arguments = file;            
    p.StartInfo.UseShellExecute = false;
    p.StartInfo.RedirectStandardOutput = true;
    p.Start();
    p.WaitForExit();           
    string output = p.StandardOutput.ReadToEnd();
    return output.Split(' ')[0].Substring(1).ToUpper ();
}

Ok - obrigado a todos - deixe-me concluir:

1. o uso de um exe "nativo" para fazer o hash demorou de 6 minutos a 10 segundos, o que é enorme.
2. Aumentar o buffer foi ainda mais rápido - o arquivo de 1,6 GB demorou 5,2 segundos usando o MD5 no .Net, então irei com esta solução - obrigado novamente

Eu fiz testes com tamanho de buffer, executando este código

using (var stream = new BufferedStream(File.OpenRead(file), bufferSize))
{
    SHA256Managed sha = new SHA256Managed();
    byte[] checksum = sha.ComputeHash(stream);
    return BitConverter.ToString(checksum).Replace("-", String.Empty).ToLower();
}

E eu testei com um arquivo de 29½ GB de tamanho, os resultados foram

• 10.000: 369,24s
• 100.000: 362,55s
• 1.000.000: 361,53s
• 10.000.000: 434,15s
• 100.000.000: 435,15s
• 1.000.000.000: 434,31s
• E 376,22s ao usar o código original sem buffer.

Estou executando uma CPU i5 2500K, 12 GB de RAM e uma unidade SSD OCZ Vertex 4 256 GB.

Então eu pensei, que tal um disco rígido padrão de 2 TB. E os resultados foram assim

• 10.000: 368,52s
• 100.000: 364,15s
• 1.000.000: 363,06s
• 10.000.000: 678,96s
• 100.000.000: 617,89s
• 1.000.000.000: 626,86s
• E para nenhum buffered 368,24

Então, eu recomendaria nenhum buffer ou um buffer de no máximo 1 moinho.

Você está fazendo algo errado (provavelmente um buffer de leitura muito pequeno). Em uma máquina com idade indecente (Athlon 2x1800MP de 2002) que possui DMA no disco provavelmente fora de sintonia (6.6M / s é muito lento ao fazer leituras sequenciais):

Crie um arquivo 1G com dados "aleatórios":

# dd if=/dev/sdb of=temp.dat bs=1M count=1024    
1073741824 bytes (1.1 GB) copied, 161.698 s, 6.6 MB/s

# time sha1sum -b temp.dat
abb88a0081f5db999d0701de2117d2cb21d192a2 *temp.dat

1m5.299s

# time md5sum -b temp.dat
9995e1c1a704f9c1eb6ca11e7ecb7276 *temp.dat

1m58.832s

Isso também é estranho, o md5 é consistentemente mais lento que o sha1 para mim (execute novamente várias vezes).

Sei que estou atrasado para a festa, mas realizei o teste antes de realmente implementar a solução.

Eu realizei teste contra a classe MD5 embutida e também o md5sum.exe . No meu caso, a classe incorporada levou 13 segundos, enquanto o md5sum.exe também ficou em torno de 16 a 18 segundos em cada execução.

    DateTime current = DateTime.Now;
    string file = @"C:\text.iso";//It's 2.5 Gb file
    string output;
    using (var md5 = MD5.Create())
    {
        using (var stream = File.OpenRead(file))
        {
            byte[] checksum = md5.ComputeHash(stream);
            output = BitConverter.ToString(checksum).Replace("-", String.Empty).ToLower();
            Console.WriteLine("Total seconds : " + (DateTime.Now - current).TotalSeconds.ToString() + " " + output);
        }
    }

Você pode dar uma olhada no XxHash.Net ( https://github.com/wilhelmliao/xxHash.NET )
O algoritmo do xxHash parece ser mais rápido que todos os outros.
Alguma referência no site xxHash: https://github.com/Cyan4973/xxHash

PS: Eu ainda não o usei.