En effet, deux bugs ont été constatés, l'un majeur, l'autre mineur qui ne concerne qu'une optimisation possible.

Le problème majeur provient sans doute d'une mauvaise gestion des .tar ou des .tar.*. En effet, dans le résultat final, on a bien tous les .tar.gz, mais malheureusement pas toujours leur contenu. Résultat : 360 000 hash environs au lieu des 4 500 000 attendus ! Il va falloir chercher d'où cela peut provenir.

Le deuxième problème concerne une optimisation. En fait il s'agit de la répartition de charge. Le test a porté sur un mirroir du site kernel.org/linux (dans lequel on trouve absolument tout, ou presque, sur le noyau, depuis le début). La technique de la lhm est d'obtenir la liste des fichiers a traiter et de la couper en autant de processus que désiré (c'est un paramètre). A priori cela semble correcte, hors il se trouve qu'il y a une énorme assertion là dessous : tous les fichiers ont un temps de traitement quasiment égal. Hors pour le site précité, ceci n'est absolument pas vrai, les noyaux étant à la fin du listing, résultat : on se retrouve vite avec un seul processus traitant les noyaux tout seul !! Pas très optimisé ! On peut dire que majoritairement, les fichiers qui se trouvent les uns a coté des autres ont de bonnes chances d'avoir un temps similaire. On pourrait dès lors distribuer la liste, ligne par ligne aux processus (et non plus par bloc). Cette solution à l'avantage d'être simple a mettre en oeuvre. L'idéal searit quand même de récupérer la taille du fichier, son type et de pondérer une valeur qui servirait à son classement, c'est cette liste là qu'il faudrait distribuer ligne par ligne ! Mais c'est moins simple !

Donc, vous l'aurez compris, il reste encore du boulot :)