pourquoi le nautile est-il lent?

Je me demande pourquoi Nautilus est très lent lors de l'ouverture d'un répertoire contenant de nombreux fichiers. Mon répertoire / usr / lib, par exemple, contient 1 900 fichiers et il faut environ 5+ secondes pour tout afficher. C'est comme ça depuis que j'ai installé Ubuntu il y a quelques mois et c'est parfois assez ennuyeux. Je n'ai pas de matériel puissant mais je sais que l'Explorateur Windows est tellement plus rapide que cela.

Y a-t-il quelque chose qui puisse être fait pour l'accélérer?

Ubuntu 10.04

Le suivi de l'exécution de nautilusmontre que la lenteur est due à une combinaison de deux facteurs:

• Il est intelligent d'afficher des informations utiles sur chaque fichier. Il examine le contenu des fichiers pour déterminer quelle icône utiliser et éventuellement afficher un aperçu. Cela peut être atténué en désactivant les aperçus dans les préférences.

• Il fait beaucoup de travail inutile (comme stating plusieurs fois chaque fichier, et /proc/filesystemsmême vérifier les non-répertoires). Tout ce que vous pouvez faire est d'apprendre la programmation, d'améliorer le programme et d'envoyer un patch. Ou envoyez au moins une demande de fonctionnalité aux auteurs (veuillez l'accélérer).

• Il appelle plusieurs processus externes pour chaque répertoire, je n'ai pas exploré ce qu'ils font.

Dans l'onglet "Aperçu" sous "Edition -> Préférences", essayez de basculer toutes les options sur "Jamais".

Cela m'a aussi énormément aidé à désactiver les "technologies d'assistance". Vous pouvez le faire dans "Système -> Préférences -> Technologies d'assistance". Décochez "Activer les technologies d'assistance".

Vous devrez vous déconnecter et vous reconnecter pour que cette dernière modification prenne effet.

Cela m'a rappelé une conversation que j'ai eue avec Alexander Larsson , le développeur principal de Nautilus et d'autres projets, y compris GVFS.

Giles sa réponse , en particulier le peu de Nautilus regardant à l'intérieur du contenu des fichiers, touche à la raison principale pour laquelle Nautilus est "lent". Cependant, Giles n'explique pas pourquoi cela est lent, ce qui pourrait être évident pour certains, mais pas pour d'autres. Voici ce qu'Alex avait à dire:

Disons que vous commencez avec une liste vierge, c'est-à-dire que vous n'avez pas du tout accédé au système de fichiers. Supposons maintenant que vous exécutez stat («/ some / dir / file»). Le noyau doit d'abord trouver le fichier qui, en termes techniques, est appelé l'inode. Il commence par regarder dans le superbloc du système de fichiers, qui stocke l'inode du répertoire racine. Ensuite, il ouvre le répertoire racine, en trouve «certains», l'ouvre, trouve «dir», etc. finissant par trouver l'inode pour le fichier.

Ensuite, vous devez réellement lire les données d'inode. Après la première lecture, il est également mis en cache dans la RAM. Ainsi, une lecture seule doit avoir lieu une seule fois.

Considérez le HD comme un vieux tourne-disque, une fois que vous êtes au bon endroit avec l'aiguille, vous pouvez continuer à lire des trucs rapidement pendant qu'il tourne. Cependant, une fois que vous devez déménager dans un endroit différent, appelé «chercher», vous faites quelque chose de très différent. Vous devez déplacer physiquement le bras, puis attendre que le plateau tourne jusqu'à ce que le bon endroit soit sous l'aiguille. Ce type de mouvement physique est intrinsèquement lent, donc les temps de recherche de disques sont assez longs.

Alors, quand cherchons-nous? Cela dépend bien sûr de la disposition du système de fichiers. Les systèmes de fichiers essaient de stocker les fichiers consécutivement pour augmenter les performances de lecture, et ils essaient généralement de stocker les inodes pour un seul répertoire les uns à côté des autres, mais tout dépend de choses comme le moment où les fichiers sont écrits, la fragmentation du système de fichiers, etc. Donc, dans le pire des cas cas, chaque statistique d'un fichier provoquera une recherche, puis chaque ouverture du fichier provoquera une deuxième recherche. C'est pourquoi les choses prennent autant de temps lorsque rien n'est mis en cache.

Certains systèmes de fichiers sont meilleurs que d'autres, la défragmentation peut aider. Vous pouvez faire certaines choses dans les applications. Par exemple, GIO trie les inodes reçus de readdir () avant de les déclarer en espérant que le numéro d'inode a une sorte de relation avec l'ordre du disque (il a généralement) minimisant ainsi les recherches aléatoires d'avant en arrière.

Une chose importante est de concevoir votre stockage de données et vos applications pour minimiser la recherche. Par exemple, c'est pourquoi Nautilus lisant / usr / bin est lent, car les fichiers qu'il contient n'ont généralement pas d'extension dont nous avons besoin pour effectuer un reniflement magique pour chacun. Donc, nous devons ouvrir chaque fichier => une recherche par fichier => slooooow. Un autre exemple est celui des applications qui stockent des informations dans de nombreux petits fichiers, comme le faisait gconf, également une mauvaise idée. Quoi qu'il en soit, dans la pratique, je ne pense pas que vous puissiez faire grand-chose, sauf essayer de masquer les latences.

Il a terminé avec la note suivante:

La vraie solution pour tout ce dilemme est de s'éloigner des médias en rotation. J'entends que les SSD Intel sont géniaux. Linus ne jure que par eux.

:-)

J'ai finalement compris ce qui rend le nautilus si lent: les signets.

Pour y remédier, supprimez tous vos signets, redémarrez, puis rajoutez ceux dont vous ne pouvez pas vous passer.

En utilisant strace, j'ai réalisé que nautilus indiquait beaucoup de fichiers pour chaque vue. Même les fichiers qui n'étaient pas dans le répertoire que je parcourais pendant la trace. Je pense que nautilus essaie de pré-mettre en cache ces signets.

J'avais un lecteur réseau comme signet ... c'était peut-être la raison pour laquelle nautilus prenait plusieurs secondes à charger.

Essayez d'utiliser un autre gestionnaire de fichiers tel que Thunar. Thunar est beaucoup plus rapide pour charger les listes de répertoires et plus stable pour copier des fichiers de mon disque dur USB NTFS vers ext4, bien qu'avec de grands ensembles de fichiers, il semble avoir des problèmes comme Nautilus.

Voici un lien pour le script de commutateur https://help.ubuntu.com/community/DefaultFileManager

Si vous avez installé xfce dans un système Gnome et que vous ne l'utilisez jamais, supprimez exo-utils

Il a résolu mon problème, ainsi que le problème de Chrome qui n'ouvre pas correctement les fichiers après leur téléchargement.

Dans l'onglet "Aperçu" sous "Edition -> Préférences", essayez de basculer toutes les options sur "Jamais".

Cela m'a aussi énormément aidé à désactiver les "technologies d'assistance". Vous pouvez le faire dans "Système -> Préférences -> Technologies d'assistance". Décochez "Activer les technologies d'assistance".

Vous devrez vous déconnecter et vous reconnecter pour que cette dernière modification prenne effet.