Est-ce que quelqu'un connaît-il de tout équivalent parallèle des fichiers Java.walkfiletree ou quelque chose de similaire? Cela peut être une bibliothèque Java ou Scala.
3 Réponses :
Comme d'autres l'ont souligné, la marche d'un arbre de fichiers est presque certainement liée au lieu de la CPU limitée afin que les avantages de faire une promenade d'arborescence de fichiers multithreads soient discutables. Mais si vous vouliez vraiment, vous pouvez probablement rouler le vôtre avec un Cet exemple marche chaque répertoire sur un thread séparé. Voici le didacticiel pour Java 7's Fork / Join Bibliothèque. forkjoinpool ou similaire.
S'il y a quelques fonctionnalités à effectuer sur chaque élément, des performances significatives de l'expérience passée peuvent être gagnées lors de la marche d'un arborescence de fichiers et de l'exécution de la tâche à chaque noeud simultanément VS en série.
@Hazok cela dépend de la fonctionnalité. Si la fonctionnalité est très intensive de CPU, elle peut surgir l'IO de la promenade d'un arbre de fichiers. Si tel est le cas, alors que votre code simultanément peut en valoir la peine. Cependant, ce ne sera pas toujours le cas.
D'accord, c'est pourquoi j'ai qualifié la déclaration. Je voulais juste souligner qu'il y a des cas où des gains de performance peuvent être atteints car il a été indiqué «douteux» dans la réponse.
supposons que l'exécution d'un rappel sur chaque fichier est suffisante.
Ce code ne gérera pas les boucles dans le système de fichiers - vous auriez besoin d'un registre où vous avez été pour que (par exemple collecte des fichiers à l'aide d'un pli au lieu d'un java.util.concurrent.concurthashmap ). Il y a toutes sortes d'améliorations que vous pouvez ajouter, comme signaler des exceptions au lieu d'ignorer silencieusement les ignorant. foreach n'est pas drastiquement plus difficile, mais je laisse cela comme un exercice au lecteur. (A ConcurrentLinkedQuuee est probablement assez rapide pour les accepter tout en un rappel, sauf si vous avez des fils très lents et un système de fichiers génial.)
En fait, j'espérais obtenir un lien vers la bibliothèque «mature-ish» qui le fait et a des contrats à terme supplémentaires, mais votre exemple suffit à mes besoins actuels. Merci!
Cet exercice n'est ni aussi bref que la réponse Scala, ni comme Java - comme la réponse Java.
L'idée ici était de démarrer des promenades parallèles avec quelque chose comme un fil par périphérique.
Le Les marcheurs sont sur des fils Forkjoinpool, alors quand ils lancent un avenir pour chaque test de chemin, ce sont des tâches fourchues sur la piscine. Le test de répertoire utilise un blocage géré lorsqu'il lit le répertoire, à la recherche de fichiers.
Le résultat est renvoyé en complétant une promesse en fonction du futur chemin de chemin. (Aucun mécanisme ici pour détecter l'achèvement des mains vides.)
Un test plus intéressant comprendrait la lecture de fichiers zip, puisque la décompression mangerait du processeur.
Je me demande si Paulp fera quelque chose d'intelligent avec une liste profonde .
Merci d'avoir pris autant de temps pour écrire ce code. J'ai décidé d'accepter la solution de Rex Kerr parce que c'est si bref et par celui facile à déboguer.
@Lucek Rex est le meilleur. Thx pour la question, c'était amusant explorer l'API. J'ai aussi plongé les autres réponses.
Je ne pense pas que cela a du sens parce que tous les fils parallèles auront le même goulot d'étranglement - HDD. Et cela ne peut pas être mis en place comme des opérations de réseau IO.
Pourquoi promener votre arbre de fichiers en parallèle une bonne idée? Ceci est généralement lié à IO, pas de CPU lié.
Dans mon traitement de dossier, le processeur est lié à la CPU et l'utilisation d'E / S est d'environ 10% à 20%.