lhm - tests
develLes tests sont finis, les conclusions sont terribles ....
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 :)