Pourquoi est GNU trouver si rapide 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 tous les sous-répertoires.
find ~/ -name "bogus" me donne ces informations après quelques secondes, pourtant le gestionnaire de fichiers dolphin de KDE a nécessité près de 3 minutes pour faire de même. Cela correspond à mon expérience précédente avec GNOME beagle .
Comment find parvient-il à 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 Dolphin avec Baloo en particulier, il semble rechercher les métadonnées de chaque fichier dans son domaine de recherche, même si vous effectuez une recherche de nom de fichier simple. Lorsque je trace le file.so processus, je vois à nouveau des appels à lstat, getxattr et getxattr pour chaque fichier, et même pour .. entrées. Ces appels système récupèrent des métadonnées sur le fichier qui est stocké dans 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 le inode ). Interroger les métadonnées d'un fichier plusieurs fois est bon marché car les données seraient dans le cache disque, mais il peut y avoir une différence significative entre interroger les métadonnées et ne pas interroger les métadonnées.
find est beaucoup plus intelligent. Il essaie d'éviter les appels système inutiles. Il n'appellera pas getxattr car il ne recherche pas sur la base d'attributs étendus. Lorsqu'il parcourt un répertoire, il peut avoir besoin d'appeler lstat sur des noms de fichiers non correspondants car il peut s'agir d'un sous-répertoire pour effectuer une recherche récursive (lstat est l'appel système qui renvoie les métadonnées du fichier, y compris le fichier type tel que normal/directory/symlink /…). Cependant find a une optimisation: il sait combien de sous-répertoires un répertoire a de son nombre de liens , et il arrête d'appeler lstat une fois qu'il sait qu'il a traversé tous les sous-répertoires . En particulier, dans un répertoire feuille (un répertoire sans sous-répertoires), find vérifie uniquement 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 de répertoire afin que find n'ait même pas besoin d'appeler lstat si c'est la seule information dont il a besoin.
Si vous exécutez find avec des options qui nécessitent de vérifier les métadonnées, il fera plus d'appels lstat, mais il ne fera toujours pas d'appel lstat sur un fichier s'il n'a pas besoin des informations (par exemple parce que le fichier est exclu par une condition précédente correspondant au nom).
Je soupçonne que d'autres outils de recherche GUI qui réinventent la roue find sont également moins intelligents que l'utilitaire de ligne de commande qui a subi des décennies d'optimisation. Dolphin, au moins, est assez intelligent pour utiliser la base de données de localisation si vous recherchez "partout" (avec la limitation qui n'est pas claire dans l'interface utilisateur que les résultats peuvent être obsolètes).