Tại sao nautilus chậm?

Tôi tự hỏi tại sao Nautilus rất chậm khi mở một thư mục chứa nhiều tệp. Ví dụ: thư mục của tôi / usr / lib có 1900 tệp và mất khoảng hơn 5 giây để hiển thị mọi thứ. Nó đã như thế này kể từ khi tôi cài đặt Ubuntu vài tháng trước và đôi khi nó thực sự khá khó chịu. Tôi không có phần cứng mạnh mẽ nhưng tôi biết rằng Windows Explorer nhanh hơn thế này rất nhiều.

Có bất cứ điều gì có thể được thực hiện để tăng tốc nó?

Ubuntu 10.04

Theo dõi việc thực hiện nautiluscho thấy sự chậm chạp là do sự kết hợp của hai yếu tố:

• Thật thông minh về việc hiển thị thông tin hữu ích về mỗi tệp. Nó nhìn vào bên trong nội dung của các tệp để xác định biểu tượng nào sẽ sử dụng và có thể hiển thị bản xem trước. Điều này có thể được giảm bớt bằng cách tắt xem trước trong các tùy chọn.

• Nó thực hiện rất nhiều công việc vô ích (chẳng hạn như stating từng tệp nhiều lần và kiểm tra /proc/filesystemsngay cả đối với các thư mục không). Tất cả những gì bạn có thể làm là học lập trình, cải thiện chương trình và gửi một bản vá. Hoặc ít nhất gửi cho tác giả một yêu cầu tính năng (vui lòng thực hiện nhanh hơn).

• Nó gọi một số quy trình bên ngoài cho mỗi thư mục, tôi chưa khám phá những gì họ làm.

Trong tab "Xem trước" trong "Chỉnh sửa -> Tùy chọn", hãy thử chuyển tất cả các tùy chọn thành "Không bao giờ".

Nó cũng giúp tôi rất nhiều để tắt "Công nghệ hỗ trợ". Bạn có thể làm điều này trong "Hệ thống -> Tùy chọn -> Công nghệ hỗ trợ". Bỏ chọn "Kích hoạt công nghệ hỗ trợ".

Bạn sẽ phải đăng xuất và đăng nhập lại để thay đổi sau có hiệu lực.

Điều này làm tôi nhớ đến một cuộc nói chuyện tôi đã có với Alexander Larsson , nhà phát triển chính của Nautilus và các dự án khác bao gồm GVFS.

Giles câu trả lời của anh ấy , cụ thể là một chút về Nautilus nhìn vào bên trong nội dung của các tập tin, chạm vào lý do chính tại sao Nautilus lại "chậm". Tuy nhiên, Giles không giải thích lý do tại sao điều này chậm, có thể rõ ràng với một số người, nhưng không phải với những người khác. Đây là những gì Alex đã nói:

Giả sử bạn bắt đầu với một bản trống, tức là bạn chưa truy cập hệ thống tập tin. Bây giờ hãy nói rằng bạn chạy stat (khác / một số / dir / tập tin). Đầu tiên kernel phải tìm tập tin, theo thuật ngữ kỹ thuật được gọi là inode. Nó bắt đầu bằng cách tìm trong siêu khối hệ thống tập tin, nơi lưu trữ inode của thư mục gốc. Sau đó, nó mở thư mục gốc, tìm thấy một số tên lửa, mở đó, tìm thấy thư mục dir, v.v ... cuối cùng cũng tìm được inode cho tập tin.

Sau đó, bạn phải thực sự đọc dữ liệu inode. Sau lần đọc đầu tiên, nó cũng được lưu trong bộ nhớ cache. Vì vậy, một lần đọc chỉ phải xảy ra một lần.

Hãy nghĩ về HD giống như một máy ghi âm cũ, một khi bạn đang ở đúng vị trí với cây kim, bạn có thể tiếp tục đọc nội dung nhanh khi nó quay. Tuy nhiên, một khi bạn cần chuyển đến một địa điểm khác, được gọi là Tìm kiếm, bạn đang làm điều gì đó rất khác. Bạn cần di chuyển vật lý cánh tay, sau đó đợi cho đĩa quay cho đến khi đúng vị trí dưới kim. Loại chuyển động vật lý này vốn đã chậm nên thời gian tìm kiếm đĩa khá dài.

Vậy, khi nào chúng ta tìm kiếm? Nó phụ thuộc vào cách bố trí hệ thống tập tin của khóa học. Các hệ thống tệp cố gắng lưu trữ các tệp liên tiếp để tăng hiệu suất đọc và chúng thường cố gắng lưu trữ các nút cho một thư mục gần nhau nhưng tất cả phụ thuộc vào những thứ như khi các tệp được ghi, phân mảnh hệ thống tệp, v.v. trong trường hợp, mỗi chỉ số của một tệp sẽ gây ra tìm kiếm và sau đó mỗi lần mở tệp sẽ gây ra tìm kiếm thứ hai. Vì vậy, đó là lý do tại sao mọi thứ mất một thời gian dài như vậy khi không có gì được lưu trữ.

Một số hệ thống tập tin tốt hơn những hệ thống khác, phân mảnh có thể giúp ích. Bạn có thể làm một số điều trong ứng dụng. Chẳng hạn, GIO sắp xếp các nút nhận được từ readdir () trước khi cho biết họ hy vọng rằng số inode có một số loại liên quan đến thứ tự đĩa (thường có) do đó giảm thiểu tìm kiếm ngẫu nhiên qua lại.

Một điều quan trọng là thiết kế lưu trữ dữ liệu và ứng dụng của bạn để giảm thiểu tìm kiếm. Ví dụ, đây là lý do tại sao Nautilus đọc / usr / bin chậm, vì các tệp trong đó thường không có phần mở rộng, chúng ta cần thực hiện phép thuật đánh hơi cho mỗi loại. Vì vậy, chúng ta cần mở từng tệp => một tìm kiếm cho mỗi tệp => slooooow. Một ví dụ khác là các ứng dụng lưu trữ thông tin trong rất nhiều tệp nhỏ, như gconf đã từng làm, cũng là một ý tưởng tồi. Dù sao, trong thực tế tôi không nghĩ có nhiều việc bạn có thể làm ngoại trừ cố gắng che giấu độ trễ.

Ông kết thúc với ghi chú sau:

Cách khắc phục thực sự cho toàn bộ vấn đề nan giải này là tránh xa phương tiện quay. Tôi nghe thấy SSD Intel là tuyệt vời. Linus thề với họ.

:-)

Cuối cùng tôi đã tìm ra thứ đang khiến nautilus trở nên chậm chạp: bookmark.

Để khắc phục, hãy xóa tất cả dấu trang của bạn, khởi động lại và sau đó thêm lại những dấu trang bạn không thể sống.

Sử dụng strace tôi nhận ra rằng nautilus đã nêu rất nhiều tệp cho mỗi lượt xem. Ngay cả các tập tin không có trong thư mục tôi đã duyệt trong quá trình theo dõi. Tôi nghĩ rằng nautilus đang cố gắng lưu trước bộ đệm này.

Tôi có một ổ đĩa mạng như một dấu trang ... đây có thể là lý do tại sao nautilus mất vài giây để tải.

Hãy thử sử dụng một trình quản lý tệp thay thế như Thunar. Thunar nhanh hơn nhiều trong việc tải danh sách thư mục và ổn định hơn để sao chép các tệp từ ổ cứng USB NTFS của tôi sang ext4, mặc dù với các tập tin lớn có vẻ như nó có vấn đề như Nautilus.

Đây là một liên kết cho tập lệnh chuyển đổi https://help.ubfox.com/community/DefaultFileManager

Nếu bạn đã cài đặt xfce trong hệ thống Gnome và bạn sẽ không bao giờ sử dụng nó, hãy xóa exo-utils

Nó đã khắc phục sự cố của tôi, cùng với sự cố Chrome không mở tệp chính xác sau khi họ tải xuống.

Trong tab "Xem trước" trong "Chỉnh sửa -> Tùy chọn", hãy thử chuyển tất cả các tùy chọn thành "Không bao giờ".

Nó cũng giúp tôi rất nhiều để tắt "Công nghệ hỗ trợ". Bạn có thể làm điều này trong "Hệ thống -> Tùy chọn -> Công nghệ hỗ trợ". Bỏ chọn "Kích hoạt công nghệ hỗ trợ".

Bạn sẽ phải đăng xuất và đăng nhập lại để thay đổi sau có hiệu lực.