我想知道为什么 Nautilus 在打开包含大量文件的目录时速度很慢。例如，我的 /usr/lib 目录有 1900 个文件，显示所有内容大约需要 5 秒以上。自从几个月前安装 Ubuntu 以来，情况一直如此，有时真的很烦人。我没有强大的硬件，但我知道 Windows 资源管理器比这快得多。
有什么办法可以加快这一速度吗？
Ubuntu 10.04
答案1
跟踪执行过程nautilus表明，速度缓慢是由于两个因素的结合造成的：
它能够智能地显示每个文件的有用信息。它会查看文件内容以确定要使用的图标，并可能显示预览。可以通过在首选项中关闭预览来降低此要求。
它做了很多无用的工作（例如
stat多次检查每个文件，/proc/filesystems甚至检查非目录）。您所能做的就是学习编程，改进程序并发送补丁。或者至少向作者发送功能请求（请使其更快）。它为每个目录调用几个外部进程，我还没有探究它们的作用。
答案2
在“编辑 -> 首选项”下的“预览”选项卡中，尝试将所有选项切换为“从不”。
关闭“辅助技术”也帮了我大忙。您可以在“系统 -> 偏好设置 -> 辅助技术”中执行此操作。取消选中“启用辅助技术”。
您必须注销并重新登录才能使后者的更改生效。
答案3
这让我想起我曾经讨论过和亚历山大·拉尔森，Nautilus 和 GVFS 等其他项目的首席开发人员。
吉尔斯他的回答，特别是关于 Nautilus 查看文件内容的部分，触及了 Nautilus “缓慢”的主要原因。然而 Giles 没有解释为什么这很慢，有些人可能觉得很明显，但其他人却不觉得。以下是 Alex 的评价：
假设您从一张白纸开始，即您根本没有访问过文件系统。现在假设您运行 stat(“/some/dir/file”)。首先，内核必须找到文件，从技术术语上讲，它被称为 inode。它首先在文件系统超级块中查找，该超级块存储了根目录的 inode。然后它打开根目录，找到“some”，打开它，找到“dir”，等等，最终找到文件的 inode。
然后您必须实际读取 inode 数据。第一次读取后，该数据也会缓存在 RAM 中。因此，读取只需发生一次。
可以将 HD 想象成一台老式唱片机，一旦针头位于正确位置，您就可以在旋转的同时快速读取内容。但是，一旦您需要移动到不同位置（称为“寻道”），您所做的就大不相同了。您需要物理移动臂，然后等待盘片旋转，直到针头位于正确位置。这种物理运动本身就很慢，因此磁盘的寻道时间相当长。
那么，我们什么时候进行寻道呢？这当然取决于文件系统布局。文件系统尝试连续存储文件以提高读取性能，并且它们通常还尝试将单个目录的 inode 存储在彼此附近，但这一切都取决于诸如文件写入时间、文件系统碎片等因素。因此，在最坏的情况下，文件的每个状态都会导致寻道，然后每次打开文件都会导致第二次寻道。所以，这就是为什么在没有缓存的情况下事情会花费这么长时间的原因。
有些文件系统比其他文件系统更好，碎片整理可能会有所帮助。您可以在应用程序中执行某些操作。例如，GIO 在声明之前对从 readdir() 接收到的 inode 进行排序，希望 inode 编号与磁盘顺序有某种关系（通常有），从而最大限度地减少随机来回搜索。
重要的事情之一是设计您的数据存储和应用程序以尽量减少搜索。例如，这就是为什么 Nautilus 读取 /usr/bin 很慢的原因，因为那里的文件通常没有扩展名，我们需要对每个文件进行魔术嗅探。因此，我们需要打开每个文件 => 每个文件一次搜索 => 很慢。另一个例子是将信息存储在大量小文件中的应用程序，就像 gconf 以前做的那样，这也是一个坏主意。无论如何，在实践中，我认为除了试图隐藏延迟之外，你没有什么可以做的。
他最后说道：
解决这一难题的真正方法是放弃旋转介质。我听说英特尔固态硬盘 (SSD) 非常棒。Linus 对其深信不疑。
:-)
答案4
尝试使用其他文件管理器，例如 Thunar。Thunar 在加载目录列表时速度更快，在将文件从我的 NTFS usb 硬盘复制到 ext4 时也更稳定，不过对于大量文件，它似乎像 Nautilus 一样有问题。
这是切换脚本的链接 https://help.ubuntu.com/community/DefaultFileManager