Optimiser le comptage de fichiers

Le
Patrick
Bonjour,

Dans mon application Perl, je dois compter le nombre total de fichiers
(pas de répertoires) dans toute une arborescence.

Mon code actuel est le suivant :

use File::Recurse;
my $nb = 0;
recurse { -f && $nb++ } $dir;

Avec ce code je peux traiter une arbo de 10 000 fichiers en 15 secondes.

Je voudrais savoir si il existe un moyen plus rapide de le faire.

Merci de votre aide.

Patrick
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #147861
Patrick wrote in message
Dans mon application Perl, je dois compter le nombre total de fichiers
(pas de répertoires) dans toute une arborescence.


Ni de devices, ni de FIFO, ni de liens symboliques.

use File::Recurse;


Pourquoi pas plutôt File::Find, qui fait partie de la distribution
standard ?

Je voudrais savoir si il existe un moyen plus rapide de le faire.


J'en doute. Combien de temps prend un « find dir -type f > /dev/null » ?

Patrick
Le #147860
Patrick wrote in message
Dans mon application Perl, je dois compter le nombre total de fichiers
(pas de répertoires) dans toute une arborescence.


Ni de devices, ni de FIFO, ni de liens symboliques.

use File::Recurse;


Pourquoi pas plutôt File::Find, qui fait partie de la distribution
standard ?

Je voudrais savoir si il existe un moyen plus rapide de le faire.


J'en doute. Combien de temps prend un « find dir -type f > /dev/null » ?


Le File::Find marche aussi, bien sûr, avec les mêmes performances.

Je vais donc plutôt l'utiliser à la place du recurse.

Mon problème est en fait le suivant : mon programme explore les fichier s
dans une arborescence et fait des opérations complexes sur les
fichiers trouvés. J'ai besoin de connaître le nombre total de fichier s
dans l'arborescence au début du traitement pour faire évoluer une bar re
de progression pendant le traitement (qui peut être assez long).

Mon soucis actuel est que le calcul du nombre total de fichiers retarde
de plusieurs secondes (voire dizaines de secondes) le début du
traitement, ce qui est pénalisant pour l'utilisateur.

Si je ne peux pas optimiser le calcul du nombre total de fichiers, je
pourrais peut être l'exécuter en "arrière plan" et commencer tout d e
suite le traitement des fichiers ? Mais je ne sais pas comment faire cela .

Pour info, j'utilise une ancienne version de Perl (5.005) car c'est la
seule installée sur la machine sur laquelle doit tourner ce script.

Merci de votre aide.

Patrick


kurtz le pirate
Le #149755
In article Nicolas George
J'en doute. Combien de temps prend un « find dir -type f > /dev/null » ?


chez moi
time find . -type f|wc -l

donne :
66596

real 0m39.275s
user 0m0.410s
sys 0m7.810s

en interpolant, ça fait 6 secondes pour 10000 fichiers sur mon iMac
G5/1,8GHz


--
klp

Nicolas George
Le #149754
Patrick wrote in message
Mon problème est en fait le suivant : mon programme explore les fichiers
dans une arborescence et fait des opérations complexes sur les
fichiers trouvés. J'ai besoin de connaître le nombre total de fichiers
dans l'arborescence au début du traitement pour faire évoluer une barre
de progression pendant le traitement (qui peut être assez long).

Mon soucis actuel est que le calcul du nombre total de fichiers retarde
de plusieurs secondes (voire dizaines de secondes) le début du
traitement, ce qui est pénalisant pour l'utilisateur.

Si je ne peux pas optimiser le calcul du nombre total de fichiers, je
pourrais peut être l'exécuter en "arrière plan" et commencer tout de
suite le traitement des fichiers ? Mais je ne sais pas comment faire cela.


Il n'y a pas de solution idéale au problème. Déjà, il y a de bonnes chances
que faire le comptage en arrière plan ralentisse les choses. Ça dépend un
peu de la disposition, mais les cas où ce ne serait pas le cas sont
certainement rares.

D'un autre côté, faire le traitement sur tous les fichiers demande de toutes
façons de faire l'exploration. Il peut être intéressant de faire une fois
l'exploration, non seulement en comptant les fichiers, mais en notant les
chemins d'accès dans une liste, et ensuite de traiter les fichiers de la
liste. Si les fichiers sont vraiment très nombreux, c'est mauvais, mais
sinon ça peut présenter des avantages vis-à-vis du cache et des temps
d'accès.

espie
Le #149753
In article Nicolas George
Patrick wrote in message
Mon problème est en fait le suivant : mon programme explore les fichiers
dans une arborescence et fait des opérations complexes sur les
fichiers trouvés. J'ai besoin de connaître le nombre total de fichiers
dans l'arborescence au début du traitement pour faire évoluer une barre
de progression pendant le traitement (qui peut être assez long).

Mon soucis actuel est que le calcul du nombre total de fichiers retarde
de plusieurs secondes (voire dizaines de secondes) le début du
traitement, ce qui est pénalisant pour l'utilisateur.

Si je ne peux pas optimiser le calcul du nombre total de fichiers, je
pourrais peut être l'exécuter en "arrière plan" et commencer tout de
suite le traitement des fichiers ? Mais je ne sais pas comment faire cela.


Il n'y a pas de solution idéale au problème. Déjà, il y a de bonnes chances
que faire le comptage en arrière plan ralentisse les choses. Ça dépend un
peu de la disposition, mais les cas où ce ne serait pas le cas sont
certainement rares.


A priori, il y a quand meme de tres larges chances que le temps d'execution
soit ici domine par la lecture sur disque... tout depend si l'arborescence
de repertoire tient dans le cache ou pas.

Apres, pour lire en arriere-plan, ca va dependre de la plateforme. En
supposant une plate-forme decente (un Unix), on peut faire un fork pour
lire le repertoire en arriere-plan... Quant a communiquer avec le traitement
principal... on n'a que l'embarras du choix, entre un peu de memoire partagee
et un pipe.

Si on suppose que le temps de calcul est long devant le parcours de
l'arborescence, on peut demarrer avec un nombre de fichiers arbitraire,
et verifier de temps en temps si le process fils a renvoye son resultat
final, et ajuster le pourcentage affiche dans ce cas... sinon, faudra
verifier de temps en temps, et c'est de toutes facons pas gagne pour faire
ce genre de choses sans suppositions arbitraires sur un peu tout.


Nicolas George
Le #149752
Marc Espie wrote in message
A priori, il y a quand meme de tres larges chances que le temps d'execution
soit ici domine par la lecture sur disque... tout depend si l'arborescence
de repertoire tient dans le cache ou pas.


Non, tu rates quelques éléments. Il y a quand même de très bonnes chances
que les fichiers trouvés, on ait envie de les lire. Or justement, si on les
lit, et que tout ça se fait depuis le disque, il va y avoir conflit entre la
lecture du fichier, et la lecture des répertoires. Et à moins d'avoir le
droit à un ionice ou équivalent bourrin (s'il y a un perl antédiluvien sur
la machine, j'y crois peu), on se retrouve à faire pire que la somme des
deux, à cause des temps d'accès.

espie
Le #149656
In article Nicolas George
Marc Espie wrote in message
A priori, il y a quand meme de tres larges chances que le temps d'execution
soit ici domine par la lecture sur disque... tout depend si l'arborescence
de repertoire tient dans le cache ou pas.


Non, tu rates quelques éléments. Il y a quand même de très bonnes chances
que les fichiers trouvés, on ait envie de les lire. Or justement, si on les
lit, et que tout ça se fait depuis le disque, il va y avoir conflit entre la
lecture du fichier, et la lecture des répertoires. Et à moins d'avoir le
droit à un ionice ou équivalent bourrin (s'il y a un perl antédiluvien sur
la machine, j'y crois peu), on se retrouve à faire pire que la somme des
deux, à cause des temps d'accès.


Non, non, je n'avais rien rate. Ca se regarde et se mesure, je pretend.
Surtout que les infos de repertoires peuvent etre `petites' par rapport
aux infos de fichiers. Ou alors, peut-etre que le cache est relativement
grand, ce qui ne change rien pour la premiere fois ou on lit les donnees
depuis le disque.


Benoit Izac
Le #149650
Bonjour,

le 12/08/2007 à 17:42, kurtz le pirate a écrit dans le message

J'en doute. Combien de temps prend un « find dir -type f > /dev/null » ?


chez moi
time find . -type f|wc -l

donne :
66596

real 0m39.275s
user 0m0.410s
sys 0m7.810s

en interpolant, ça fait 6 secondes pour 10000 fichiers sur mon iMac
G5/1,8GHz


Ce qu'il serait plus intéressant c'est de comparer
% for i in 1 2 3 4 5; do time find / -type f 2>/dev/null >&2; done
et
% for i in 1 2 3 4 5; do time perl -MFile::Find -e
'find(sub{-f $_ && print("$File::Find::namen")}, "/")'
2>/dev/null >&2; done

--
Benoit Izac


Publicité
Poster une réponse
Anonyme