Pourquoi GNU trouve-t-il si rapidement par rapport aux utilitaires de recherche de fichiers graphiques?

J'essaie de trouver un fichier qui n'existe pas dans mon répertoire personnel et dans tous les sous-répertoires.

find ~/ -name "bogus"me donne cette information après quelques secondes, mais le gestionnaire de dolphinfichiers de KDE avait besoin de presque 3 minutes pour faire de même. Cela correspond à mon expérience précédente avec GNOMEbeagle .

Comment fait-on findpour faire la même chose très rapidement alors que la recherche graphique (qui est plus intuitive à utiliser que les paramètres de ligne de commande) traîne derrière?

En regardant spécifiquement Dolphin avec Baloo, il semble rechercher les métadonnées de chaque fichier de son domaine de recherche, même si vous effectuez une recherche simple de nom de fichier. Lorsque je trace le file.soprocessus, je vois des appels à lstat, getxattret getxattrencore pour chaque fichier, et même pour des ..entrées. Ces appels système récupèrent des métadonnées sur le fichier qui sont stockées à un emplacement différent du nom de fichier (le nom de fichier est stocké dans le contenu du répertoire, mais les métadonnées sont dans l' inode ). Interroger les métadonnées d'un fichier à plusieurs reprises est peu coûteux, car les données se trouvent dans le cache du disque, mais il peut y avoir une différence significative entre interroger les métadonnées et ne pas les interroger.

findest beaucoup plus intelligent. Il essaie d'éviter les appels système inutiles. Il n'appelle pas getxattrcar il ne recherche pas en fonction d'attributs étendus. Lorsqu'il traverse un répertoire, il peut être nécessaire d'appeler lstatdes noms de fichiers ne correspondant pas car il peut s'agir d'un sous-répertoire dans lequel effectuer une recherche récursive ( lstatc'est l'appel système qui renvoie les métadonnées du fichier, y compris le type de fichier, tel que / directory / symlink /…). Cependant, il finda une optimisation: il sait combien de sous-répertoires un répertoire a de son nombre de liens et il arrête d'appeler lstatdès qu'il sait qu'il a parcouru tous les sous-répertoires. En particulier, dans un répertoire feuille (un répertoire sans sous-répertoires),findvérifie seulement les noms, pas les métadonnées. De plus, certains systèmes de fichiers conservent une copie du type de fichier dans l’entrée du répertoire, ce qui findévite même d’appeler lstatsi c’est la seule information dont il a besoin.

Si vous utilisez finddes options nécessitant une vérification des métadonnées, les lstatappels seront plus nombreux , mais aucun lstatappel ne sera toujours effectué sur un fichier s'il n'a pas besoin des informations (par exemple, le fichier est exclu par une condition antérieure. correspondant sur le nom).

Je suppose que les autres outils de recherche d'interface graphique qui réinventent la findroue sont également moins intelligents que l'utilitaire de ligne de commande, qui a subi des décennies d'optimisation. Dolphin, du moins, est suffisamment intelligent pour utiliser la base de données de localisation si vous effectuez une recherche «partout» (avec la limitation qui n’est pas claire dans l’UI que les résultats risquent d’être obsolètes).