Comment comparer rapidement deux fichiers à l'aide de .NET ?

Question

Approches typiques recommande de lire le binaire via FileStream et de le comparer octet par octet.

• Une comparaison de somme de contrôle telle que le CRC serait-elle plus rapide ?
• Existe-t-il des bibliothèques .NET qui peuvent générer une somme de contrôle pour un fichier ?

Answer 1

La méthode la plus lente possible consiste à comparer deux fichiers octet par octet. La méthode la plus rapide que j'ai pu trouver est une comparaison similaire, mais au lieu d'un octet à la fois, vous utiliseriez un tableau d'octets de taille Int64, puis vous compareriez les nombres résultants.

Voici ce que j'ai trouvé :

    const int BYTES_TO_READ = sizeof(Int64);

    static bool FilesAreEqual(FileInfo first, FileInfo second)
    {
        if (first.Length != second.Length)
            return false;

        int iterations = (int)Math.Ceiling((double)first.Length / BYTES_TO_READ);

        using (FileStream fs1 = first.OpenRead())
        using (FileStream fs2 = second.OpenRead())
        {
            byte[] one = new byte[BYTES_TO_READ];
            byte[] two = new byte[BYTES_TO_READ];

            for (int i = 0; i < iterations; i++)
            {
                 fs1.Read(one, 0, BYTES_TO_READ);
                 fs2.Read(two, 0, BYTES_TO_READ);

                if (BitConverter.ToInt64(one,0) != BitConverter.ToInt64(two,0))
                    return false;
            }
        }

        return true;
    }

Lors de mes tests, j'ai pu constater que cette méthode était plus performante qu'un simple scénario ReadByte() dans un rapport de presque 3:1. Sur une moyenne de 1000 exécutions, j'ai obtenu cette méthode à 1063 ms, et la méthode ci-dessous (comparaison directe octet par octet) à 3031 ms. Le hachage est toujours revenu à moins d'une seconde avec une moyenne de 865 ms. Ces tests ont été effectués avec un fichier vidéo d'environ 100 Mo.

Voici les méthodes ReadByte et hashing que j'ai utilisées, à titre de comparaison :

    static bool FilesAreEqual_OneByte(FileInfo first, FileInfo second)
    {
        if (first.Length != second.Length)
            return false;

        using (FileStream fs1 = first.OpenRead())
        using (FileStream fs2 = second.OpenRead())
        {
            for (int i = 0; i < first.Length; i++)
            {
                if (fs1.ReadByte() != fs2.ReadByte())
                    return false;
            }
        }

        return true;
    }

    static bool FilesAreEqual_Hash(FileInfo first, FileInfo second)
    {
        byte[] firstHash = MD5.Create().ComputeHash(first.OpenRead());
        byte[] secondHash = MD5.Create().ComputeHash(second.OpenRead());

        for (int i=0; i<firstHash.Length; i++)
        {
            if (firstHash[i] != secondHash[i])
                return false;
        }
        return true;
    }

Answer 2

Une comparaison de somme de contrôle sera très probablement plus lente qu'une comparaison octet par octet.

Pour générer une somme de contrôle, vous devez charger chaque octet du fichier et effectuer un traitement sur celui-ci. Vous devrez ensuite faire de même avec le second fichier. Le traitement sera presque certainement plus lent que la vérification par comparaison.

Quant à la génération d'une somme de contrôle, vous pouvez le faire facilement avec les classes de cryptographie. Voici un bref exemple de génération d'une somme de contrôle MD5 avec C#.

Cependant, une somme de contrôle peut être plus rapide et avoir plus de sens si vous pouvez précalculer la somme de contrôle du cas "test" ou "de base". Si vous avez un fichier existant et que vous vérifiez si un nouveau fichier est identique à l'existant, le précalcul de la somme de contrôle sur votre fichier "existant" signifierait que vous n'auriez besoin de faire le DiskIO qu'une seule fois, sur le nouveau fichier. Cela serait probablement plus rapide qu'une comparaison octet par octet.

Answer 3

En plus de Reed Copsey La réponse de la Commission :

• Le pire cas est celui où les deux fichiers sont identiques. Dans ce cas, il est préférable de comparer les fichiers octet par octet.

• Si les deux fichiers ne sont pas identiques, vous pouvez accélérer un peu les choses en détectant plus tôt qu'ils ne sont pas identiques.

Par exemple, si les deux fichiers sont de longueur différente, vous savez qu'ils ne peuvent pas être identiques, et vous n'avez même pas besoin de comparer leur contenu réel.

Answer 4

Il devient encore plus rapide si vous ne lisez pas par petits morceaux de 8 octets mais si vous faites une boucle autour, en lisant un plus grand morceau. J'ai réduit le temps moyen de comparaison à 1/4.

    public static bool FilesContentsAreEqual(FileInfo fileInfo1, FileInfo fileInfo2)
    {
        bool result;

        if (fileInfo1.Length != fileInfo2.Length)
        {
            result = false;
        }
        else
        {
            using (var file1 = fileInfo1.OpenRead())
            {
                using (var file2 = fileInfo2.OpenRead())
                {
                    result = StreamsContentsAreEqual(file1, file2);
                }
            }
        }

        return result;
    }

    private static bool StreamsContentsAreEqual(Stream stream1, Stream stream2)
    {
        const int bufferSize = 2048 * 2;
        var buffer1 = new byte[bufferSize];
        var buffer2 = new byte[bufferSize];

        while (true)
        {
            int count1 = stream1.Read(buffer1, 0, bufferSize);
            int count2 = stream2.Read(buffer2, 0, bufferSize);

            if (count1 != count2)
            {
                return false;
            }

            if (count1 == 0)
            {
                return true;
            }

            int iterations = (int)Math.Ceiling((double)count1 / sizeof(Int64));
            for (int i = 0; i < iterations; i++)
            {
                if (BitConverter.ToInt64(buffer1, i * sizeof(Int64)) != BitConverter.ToInt64(buffer2, i * sizeof(Int64)))
                {
                    return false;
                }
            }
        }
    }
}

Answer 5

La seule chose qui pourrait rendre une comparaison de somme de contrôle légèrement plus rapide qu'une comparaison octet par octet est le fait que vous lisez un fichier à la fois, ce qui réduit quelque peu le temps de recherche de la tête du disque. Ce léger gain peut cependant très bien être absorbé par le temps supplémentaire de calcul du hachage.

En outre, la comparaison des sommes de contrôle n'a bien sûr aucune chance d'être plus rapide que si les fichiers sont identiques. S'ils ne le sont pas, une comparaison octet par octet s'arrêterait à la première différence, ce qui la rendrait beaucoup plus rapide.

Vous devez aussi considérer qu'une comparaison de code de hachage vous indique seulement que c'est très probable que les fichiers sont identiques. Pour être sûr à 100%, vous devez faire une comparaison octet par octet.

Si le code de hachage, par exemple, est de 32 bits, vous êtes certain à 99,99999998 % que les fichiers sont identiques si les codes de hachage correspondent. C'est proche de 100 %, mais si vous avez vraiment besoin d'une certitude à 100 %, ce n'est pas le cas.