Je crois que tu oublies une remarque importante.

XmlSerializer est une classe de sérialisation légère qui permet de sérialiser un objet avec ses champs public. Mais les champs "private", utilisés par la logique interne d'un objet, ne sont pas sérialisés! De plus, on ne peut pas sérialiser les HashTable.

Pour une sérialisation XML complète, il faut utiliser la classe SoapFormatter.

> et pour éviter que l appli se freeze je mettais tout ça dans un thread , mais dans la fonction directement c'est beaucoup mieux !

En fait c'est mieux de le mettre dans un 2e Thread, mais dans les sources que j'ai téléchargées ici, tu fais tout dans le même. Et puis, quand tu crées un 2e Thread, il y a un problème: seul le Thread de l'interface graphique est capable de modifier l'interface graphique, donc dans un 2e Thread, la progressBar ne bougerais pas (même si je n'ai pas testé mais c'est toujours le même problème avec les interfaces graphiques WinForms). Quand un 2e Thread doit modifier l'interface graphique, il faut utiliser un delegate et différer son exécution mais bon, on va dire que c'est hors sujet! L'avantage majeur d'utiliser un 2e Thread c'est que, quand l'utilisateur clique sur la croix pour fermer le programme, le Thread graphique peut dire au 2e: Stop! Autrement dit, Thread.Abort()
Ici ce n'est pas le cas, tout se fait dans le même Thread, résultat, une fois que le calcul du CRC est commencé, impossible de l'arrêter comme ça. Alors pour l'arrêter, on pourrait ajouter une méthode Stop() à la classe, qui fait passer un booléen à false et qui permet de sortir de la boucle qui calcule le CRC. C'est juste une suggestion.

La progressBar pose un autre problème: vu la façon dont on l'utilise, la taille du fichier en bytes est passée à MaxValue qui est un int. Ca limite l'utilisation à des fichiers de maximum 2 exposant 31 bytes, autrement dit 2 gigabytes. Pour les fichiers plus gros, ça ne fonctionne pas avec cette méthode.

J'ai pour principe de toujours séparer l'interface graphique du reste du code, donc moi la progressBar je l'ai virée et je n'ai donc pas tous ces problèmes, même s'il est vrai que ça pourrait être bien de connaître le statut de la progression, mais alors via d'autres moyens comme par exemple enregistrer un callback sous la forme d'une fonction qui prend en paramètre une valeur qui représente un pourcentage de progression, par exemple.

Niveau performances, j'ai fait des tests avec plusieurs fichiers sur différents disques durs, et il me semble que la valeur idéale pour le buffer de lecture est de 16384 bytes. Ca ne va pas plus vite que 4096 bytes, mais ça consomme un peu moins de CPU. Au-delà, ça commence à ralentir donc je ne conseille pas.

J'ai encore oublié un petit détail :)

if( pBar != null )
{
   pBar.Minimum = 0;
   pBar.Maximum = (int)myStream.Length;
   pBar.Value = 0;
}

Faut mettre la valeur de la progressBar à zéro au début, voilà ;)
J'espère que tu as tout pigé, si jamais tu as des questions, n'hésite pas à me contacter.

Hello, c'est encore moi. J'ai vu que tu as changé ta source, c'est sympa. Mais j'ai encore quelques remarques.

En fait j'ai écrit une classe optimisée pour mon usage personnel en m'inspirant de ton code et d'une source en C (l'algorithme est le même, apparemment, c'est le plus rapide, en tous cas j'ai pas trouvé mieux), j'ai enlevé la progressBar, mis quelques commentaires en anglais et j'ai utilisé un Stream en entrée au lieu d'un nom de fichier. C'est un bout de ce code que je t'ai copié-collé.

Seulement, comme toi tu utilises une progressBar, il y a quelques petites choses que tu devrais changer:

1) Tout d'abord d'un point de vue purement esthétique et pratique, je ne vois pas l'intérêt du 2e paramètre, le booléen enableProgress. Si j'étais toi, je l'enlèverais et je demanderais à l'utilisateur d'attribuer la valeur null à l'argument pBar s'il ne souhaite pas de progressBar. Ensuite au lieu de tester
if(enableProgress)
tu testerais
if(pBar != null)

2) Je t'ai dit que tu n'aurais plus besoin de la variable offset, mais tu l'emploies toujours pour la progressBar. Il y a toujours moyen d'utiliser la progressBar sans cette variable, mais il faut un peu adapter ton code. Au début, remplace

long fileSize = myStream.Length;
if( enableProgress ) pBar.Maximum = ( int )fileSize + 2 ;

par

if( pBar != null )
{
   pBar.Minimum = 0;
   pBar.Maximum = (int)myStream.Length;
}

J'avoue aussi que je n'ai pas compris pourquoi tu faisais +2, normalement la taille du fichier devrait suffire. Ensuite, dans le code de la boucle, remplace:

if( enableProgress ) pBar.Value = offset ;

par

if( pBar != null )
{
   pBar.Value += readBytes;
   Application.DoEvents();
}

Le Application.DoEvents() c'est pour éviter que ton interface graphique ne plante complètement pendant le calcul du CRC32, et continue à réagir aux événements de la souris et à rester "vivante". Ceci parce que tu effectues le calcul du CRC32 dans le cadre du Thread qui s'occupe de l'affichage. Si tu n'appelles pas DoEvents() ton application est incapable de réagir à la souris ou au clic sur un bouton pendant tout le calcul ! Si tu veux éviter que quelqu'un clique sur un bouton pendant le calcul, grise les boutons ou change le pointeur en sablier avant le calcul et revient à la normale après, mais laisse le DoEvents(), ça évitera à Windows de croire que le programme est planté si tu t'acharnes à la souris dessus.

3) Dernière remarque, mais cela je suppose que tu le sais déjà, le calcul est plus rapide lorsque le code est compilé en mode Release par rapport au mode Debug.

petites précisions:
- j'ai donc déclaré readBytes en tant que int juste avant cette boucle.
- BUFFER_SIZE est une constante qui est la taille du buffer, dans ton exemple c'était 4096 mais personnellement je l'ai augmentée à 16384.

Pour la lecture, ceci devrait suffire et plus besoin des variables offset, ni diff, ni fileSize:

            // Read the Stream to its end and fill the buffer
            while( ( readBytes = stream.Read(buffer, 0, BUFFER_SIZE) ) != 0 )
            {                
                // Compute the new CRC32 for the current buffer content
                for(int i=0; i < readBytes; ++i)
                {
                    crc32 = ( crc32 >> 8 ) ^ lookupTable[ ( crc32 & 0xFF ) ^ buffer[i] ];
                }
            }

Pour les ToString(), effectivement je n'avais pas fait attention au fait que la portion de code est commentée :)

Par contre, pour la lecture, je comprend ce que tu veux faire mais je t'explique que ce n'est pas la bonne façon de faire. Si tu demandes à lire 4096 bytes dans un Stream, tu peux très bien te retrouver par exemple avec 4090 bytes même si tu en as demandé 4096 et qu'il reste plus de 4096 bytes à lire, il faut donc toujours tester quel est le nombre de bytes que la fonction Read renvoie. Je posterai le code correct plus tard dans la journée.

Les ToString() pendant la création de la lookup table, ça me paraît totalement farfelu!

De plus, tu pourrais générer la table uniquement la première fois que la fonction est appelée et ensuite la laisser en mémoire, pour gagner un peu de temps lors des appels suivants à la méthode.

Quant à la lecture dans le fichier, tu peux la faire directement avec

int bytesLus = myStream.Read( byteArray , 0 , 4096 );

sans calculer la taille restate auparavant. La méthode Read renvoie le nombre de bytes effectivement lus. Attention, elle peut très bien en renvoyer moins que la taille du buffer même si on n'est pas à la fin du fichier! (même si c'est très improbable). C'est écrit dans la documentation du SDK:

Stream.Read: Valeur de retour: Nombre total d'octets lus dans la mémoire tampon. Cela peut être inférieur au nombre d'octets demandé si ce nombre n'est pas actuellement disponible ou égal à zéro (0) si la fin du flux a été atteinte.

Ce code utilise ActiveX et par conséquent ne fonctionne que dans Microsoft Internet Exploser, de plus uniquement sous Windows, ce qui est très dommage.

Concernant le code original, il est bien, mais le start est mal fait. J'enlèverais le

TimerRunning = true;

de la fonction display() et j'écrirais le start() comme cela:

function start() {
   if(! TimerRunning) {
      TimerRunning = true;
      display();
   }
}