Suite à mon précédent article j'ai commencé à utiliser le script "create-duplicate-list" sur une large quantité de fichiers, dont je savais que plusieurs copies surnuméraires existaient.
Le nombre de fichiers étant conséquent (147437), certains étant volumineux et le tout stocké sur un disque mécanique je savais qu'il faudrait du temps pour générer une liste. Néanmoins, après plusieurs utilisations, le temps d'exécution me paraissait tout de même élevé, malgré les améliorations apportéees.
En examinant de plus près le code et les fichiers temporaires un constat s'est imposé : le nouveau script n'était pas plus efficace que l'ancien. Une simple étape de substitution manquait. Le code manquant avait bien été préparé mais, pour une raison obscure, n'avait pas été intégré au script...
Résultat du script originel :
[ 2020-04-11 14:29:01 ] Listing file sizes...
[ 2020-04-11 14:29:18 ] Computing MD5 checksums...
[ 2020-04-11 15:31:51 ] Done.
[ 2020-04-11 15:31:52 ] Sorting the list...
[ 2020-04-11 15:31:52 ] Done.
[ 2020-04-11 15:31:52 ] Listing duplicates...
[ 2020-04-11 15:31:52 ] Done.
[ 2020-04-11 15:31:52 ] Generating the CSV file...
[ 2020-04-11 15:31:56 ] Done.
Soit un délai d'exécution d'environ une heure.
Résultats du script après correction (et un arrêt complet du système pour éviter des phénomènes de cache) :
[ 2020-04-11 16:05:00 ] Listing file sizes...
[ 2020-04-11 16:05:18 ] Computing MD5 checksums...
[ 2020-04-11 16:18:26 ] Done.
[ 2020-04-11 16:18:26 ] Sorting the list...
[ 2020-04-11 16:18:26 ] Done.
[ 2020-04-11 16:18:26 ] Listing duplicates...
[ 2020-04-11 16:18:26 ] Done.
[ 2020-04-11 16:18:26 ] Generating the CSV file...
[ 2020-04-11 16:18:31 ] Done.
Ce qui nous donne un délai d'exécution d'environ... 13 minutes ! Et un résultat identique.
En observant les fichiers temporaires produits par le script, il est possible de voir que la version originelle liste autant de fichiers à traiter que ceux présent sur le disque. La version corrigée n'en liste que 87945. Ce qui était bien le but de l'optimisation recherchée.
Ce qui m'amène au titre de cet article : tester son code est essentiel. Vous devez bien évidemment vérifier la logique et la syntaxe, mais l'environnement et les données que vous utilisez sont tout aussi importants.
Travailler sur un jeu de données limitées permet de conduire des tests rapidement, mais il faut veiller à ce que ce jeu de données soit aussi proche de la réalité que possible (variété de types de fichiers, de tailles, arborescence, ...). Des tests en conditions trop homogènes conduiront à la découverte de bugs une fois votre application déployée en production.
publié le 11 avril 2020