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
Patrick wrote in message <46bf0fd8$0$422$:
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
Patrick wrote in message <46bf0fd8$0$422$426a34cc@news.free.fr>:
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.
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
In article <46bf121b$0$421$, Nicolas George <nicolas$ wrote:
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
In article <46bf121b$0$421$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:
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
In article <46bf121b$0$421$, Nicolas George <nicolas$ wrote:
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
Patrick wrote in message <46bf25e7$0$427$:
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.
Patrick wrote in message <46bf25e7$0$427$426a34cc@news.free.fr>:
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.
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
In article <46bf3092$0$415$, Nicolas George <nicolas$ wrote:
Patrick wrote in message <46bf25e7$0$427$:
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.
In article <46bf3092$0$415$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:
Patrick wrote in message <46bf25e7$0$427$426a34cc@news.free.fr>:
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.
In article <46bf3092$0$415$, Nicolas George <nicolas$ wrote:
Patrick wrote in message <46bf25e7$0$427$:
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
Marc Espie wrote in message <f9nf8b$14at$:
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.
Marc Espie wrote in message <f9nf8b$14at$1@biggoron.nerim.net>:
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.
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
In article <46bf4f47$0$402$, Nicolas George <nicolas$ wrote:
Marc Espie wrote in message <f9nf8b$14at$:
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.
In article <46bf4f47$0$402$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:
Marc Espie wrote in message <f9nf8b$14at$1@biggoron.nerim.net>:
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.
In article <46bf4f47$0$402$, Nicolas George <nicolas$ wrote:
Marc Espie wrote in message <f9nf8b$14at$:
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
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
Bonjour,
le 12/08/2007 à 17:42, kurtz le pirate a écrit dans le message
<kurtzlepirate-26FA36.17424212082007@news-3.proxad.net> :
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
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
