mengapa nautilus lambat?


19

Saya bertanya-tanya mengapa Nautilus sangat lambat ketika membuka direktori yang berisi banyak file. Dir / usr / lib saya misalnya memiliki 1900 file dan dibutuhkan sekitar 5+ detik untuk menampilkan semuanya. Sudah seperti ini sejak saya menginstal Ubuntu beberapa bulan yang lalu dan kadang-kadang sangat mengganggu. Saya tidak memiliki perangkat keras yang kuat tetapi saya tahu bahwa Windows Explorer jauh lebih cepat dari ini.

Adakah yang bisa dilakukan untuk mempercepatnya?

Ubuntu 10,04


1
Dugaan saya adalah bahwa Nautilus menggunakan ls untuk membuat daftar sementara Explorer memiliki cache.
digitxp

Sistem apa itu? Saya pikir ini adalah faktor besar. Ini akan menjadi "lambat" di netbook saya, tetapi tidak begitu banyak pada i7 dengan dengan 4 + GB ram.
Chris

Terkait pada Tanya Ubuntu: Nautilus sangat lambat
slhck

Jawaban:


27

Menelusuri pelaksanaan nautilusmenunjukkan bahwa kelambatan ini disebabkan oleh kombinasi dari dua faktor:

  • Cerdas menampilkan informasi bermanfaat tentang setiap file. Itu terlihat di dalam isi file untuk menentukan ikon apa yang digunakan, dan mungkin menampilkan pratinjau. Ini dapat dikurangi dengan mematikan pratinjau dalam preferensi.

  • Itu banyak pekerjaan yang tidak berguna (seperti statsetiap file beberapa kali, dan memeriksa /proc/filesystemsbahkan untuk non-direktori). Yang dapat Anda lakukan adalah mempelajari pemrograman, meningkatkan program, dan mengirim tambalan. Atau setidaknya mengirim penulis permintaan fitur (harap membuatnya lebih cepat).

  • Ini memanggil beberapa proses eksternal untuk setiap direktori, saya belum mengeksplorasi apa yang mereka lakukan.


Jawaban bagus: D! +1 untuk penambalan + featureerequestrequest: D
BloodPhilia

Saya seorang programmer, meskipun belum cukup baik untuk berkontribusi. Hanya ingin tahu, bagaimana Anda melacak?
Coding District

2
@ Serek: di strace -f -ttt -p1234 -o nautilus.stracemana 1234 adalah pid dari nautilus. Saya belum menganalisis jejak secara rinci, hanya melihat sekilas ke atas (banyak hal yang melibatkan subproses) dan hal-hal per-file (beberapa stats, dan openuntuk beberapa file).
Gilles 'SANGAT berhenti menjadi jahat'

1
Banyak stat () banyak berasal dari panggilan perpustakaan, banyak dari glibc.
Tim Post

woah, ini sudah menjadi masalah sejak lebih dari 6 tahun! kenapa masih ada yang menginvestasikan waktu dalam hal ini? Untuk memulainya, pratinjau & statistik harus dilakukan SETELAH daftar file. Dengan demikian, daftar folder besar akan instan lsdan penjelajahan akan dimungkinkan saat pratinjau dimuat. Windows Explorer berfungsi seperti ini, jika saya ingat dengan benar. Agak sulit dipercaya untuk program Ubuntu yang sangat sering digunakan seperti ini. Namun, jangan mengeluh tetapi berkontribusi sebagai gantinya
phil294

5

Di tab "Pratinjau" di bawah "Edit -> Preferensi", coba alihkan semua opsi ke "Jangan".

Ini juga sangat membantu saya mematikan "Teknologi Bantu". Anda dapat melakukan ini di "Sistem -> Preferensi -> Teknologi Bantu". Hapus centang "Aktifkan teknologi bantu".

Anda harus keluar dan kembali agar perubahan yang terakhir berlaku.


Ini memberi saya perbaikan yang sangat sederhana. Menghapus bookmark membuat perbedaan yang jauh lebih besar.
Peter Jenkins

5

Ini mengingatkan saya pada pembicaraan saya dengan Alexander Larsson , pengembang utama untuk Nautilus dan proyek lainnya termasuk GVFS.

Giles jawabannya , khususnya sedikit tentang Nautilus melihat ke dalam isi file, menyentuh alasan utama mengapa Nautilus "lambat". Namun Giles tidak menjelaskan mengapa ini lambat, yang mungkin jelas bagi sebagian orang, tetapi tidak bagi yang lain. Inilah yang dikatakan Alex:

Katakanlah Anda mulai dengan papan tulis kosong, yaitu Anda belum mengakses sistem file sama sekali. Sekarang katakan Anda menjalankan stat ("/ some / dir / file"). Pertama kernel harus mencari file, yang dalam istilah teknis disebut inode. Itu dimulai dengan melihat pada superblock filesystem, yang menyimpan inode dari direktori root. Kemudian ia membuka direktori root, menemukan "beberapa", membuka itu, menemukan "dir", dll. Akhirnya menemukan inode untuk file.

Maka Anda harus benar-benar membaca data inode. Setelah pertama kali membaca ini juga di-cache dalam RAM. Jadi, membaca hanya harus terjadi sekali.

Pikirkan HD seperti pemutar rekaman lama, begitu Anda berada di tempat yang tepat dengan jarum, Anda dapat terus membaca barang dengan cepat saat diputar. Namun, begitu Anda harus pindah ke tempat lain, yang disebut "mencari" Anda melakukan sesuatu yang sangat berbeda. Anda perlu menggerakkan lengan secara fisik, kemudian menunggu piring berputar sampai tempat yang tepat berada di bawah jarum. Gerakan fisik semacam ini secara inheren lambat sehingga mencari waktu untuk disk cukup lama.

Jadi, kapan kita mencari? Itu tergantung pada tata letak sistem file tentu saja. Filesystem mencoba untuk menyimpan file secara berurutan untuk meningkatkan kinerja membaca, dan mereka umumnya juga mencoba untuk menyimpan inode untuk satu direktori dekat satu sama lain tetapi itu semua tergantung pada hal-hal seperti ketika file ditulis, fragmentasi filesystem, dll. Jadi, yang terburuk kasus, setiap stat dari file akan menyebabkan pencarian dan kemudian setiap pembukaan file akan menyebabkan pencarian kedua. Jadi, itulah mengapa hal-hal itu memakan waktu begitu lama ketika tidak ada yang di-cache.

Beberapa sistem file lebih baik daripada yang lain, defragmentasi mungkin membantu. Anda dapat melakukan beberapa hal di aplikasi. Sebagai contoh, GIO mengurutkan inode yang diterima dari readdir () sebelum menyatakan mereka berharap bahwa nomor inode memiliki semacam hubungan dengan urutan disk (umumnya memiliki) sehingga meminimalkan pencarian acak bolak-balik.

Satu hal penting adalah merancang penyimpanan data dan aplikasi Anda untuk meminimalkan pencarian. Sebagai contoh, ini sebabnya Nautilus membaca / usr / bin lambat, karena file-file di sana umumnya tidak memiliki ekstensi yang perlu kita lakukan untuk menghirup sihir masing-masing. Jadi, kita perlu membuka setiap file => satu pencarian per file => slooooow. Contoh lain adalah aplikasi yang menyimpan informasi dalam banyak file kecil, seperti gconf yang digunakan sebelumnya, juga merupakan ide yang buruk. Ngomong-ngomong, dalam praktiknya saya tidak berpikir ada banyak yang bisa Anda lakukan kecuali mencoba menyembunyikan latensi.

Dia mengakhiri dengan catatan berikut:

Perbaikan nyata untuk seluruh dilema ini adalah menjauh dari media yang berputar. Saya mendengar SSD Intel luar biasa. Linus bersumpah demi mereka.

:-)


3
Menarik :) Namun, jika mencari adalah akar penyebab kelambatan, saya masih bertanya-tanya mengapa Windows Explorer jauh lebih cepat? Tentunya bukan karena perangkat keras.
Coding District

4
Jika saya harus menebak saya akan mengatakan itu tidak melakukan sihir sniffing tetapi hanya deteksi file berdasarkan ekstensi (saya dapat mengkonfirmasi ini untuk Windows XP).
Bruce van der Kooij

2
Persis. Explorer (untuk sebagian besar) tidak melakukan sniffing file apa pun, ia hanya menggunakan ekstensi. Jika perlu membuat pratinjau atau membaca ikon, yah, maka itu harus membuka file. Anda dapat melihat ini jika Anda membuka folder besar yang penuh dengan file .exe. Ekstensi shell dapat memaksa Explorer untuk membuka file untuk melakukan sniffing juga. Misalnya, beberapa utilitas arsip akan memeriksa file .exe untuk melihat apakah itu arsip SFX. MS telah menginvestasikan banyak upaya dalam melakukan hal-hal untuk mencoba mempercepat Explorer, baik dalam kecepatan aktual dan kecepatan nyata.
Afrazier

3

Saya akhirnya menemukan apa yang membuat nautilus sangat lambat: bookmark.

Untuk memperbaikinya hapus semua bookmark Anda, restart dan kemudian tambahkan kembali yang Anda tidak bisa hidup tanpanya.

Menggunakan strace saya menyadari bahwa nautilus menyatakan banyak file untuk setiap tampilan. Bahkan file yang tidak ada dalam direktori yang saya jelajahi selama pelacakan. Saya pikir nautilus sedang mencoba melakukan pra-cache bookmark ini.

Saya memiliki satu drive jaringan sebagai bookmark ... ini mungkin menjadi alasan mengapa nautilus mengambil beberapa detik untuk memuat.


1

Coba gunakan file manager alternatif seperti Thunar. Thunar jauh lebih cepat dalam memuat daftar direktori dan lebih stabil untuk menyalin file dari hard drive usb NTFS ke ext4, meskipun dengan set file yang besar, sepertinya ada masalah seperti Nautilus.

Berikut ini tautan untuk skrip sakelar https://help.ubuntu.com/community/DefaultFileManager


Solusi hebat! Saya suka "sudo apt-get install thunar" dan "exo-prefer--apps" kemudian pilih Thunar di (Utilities> File Manger) solusi.
Doud

1

Jika Anda telah menginstal xfce di sistem Gnome dan Anda tidak pernah menggunakannya, hapus exo-utils

Itu memperbaiki masalah saya, bersama dengan masalah Chrome tidak membuka file dengan benar setelah mereka unduh.


Tidak membantu saya. exo-utils juga dibutuhkan oleh banyak paket termasuk paket xfdesktop4 sehingga cukup sulit untuk dihapus: sudo dpkg -r --ignore-depend = terminal xfce4, thunar-volman, squeeze, thunar, xfce4-panel, xfce4-verve -plugin, xfdesktop4 exo-utils
Peter Jenkins

1

Di tab "Pratinjau" di bawah "Edit -> Preferensi", coba alihkan semua opsi ke "Jangan".

Ini juga sangat membantu saya mematikan "Teknologi Bantu". Anda dapat melakukan ini di "Sistem -> Preferensi -> Teknologi Bantu". Hapus centang "Aktifkan teknologi bantu".

Anda harus keluar dan kembali agar perubahan yang terakhir berlaku.


1
Waktu untuk membuka folder besar berkurang dari sekitar 30 detik hingga mungkin dua detik. Duka yang bagus.
wsmart

Posting saya dihapus di sini oleh pengguna lain. tampaknya. Ingin mengucapkan terima kasih kepada Jay untuk jabatannya karena itu membuat perbedaan besar untuk masalah lambat Nautius saya. Jadilah nyata, sadarlah.
wsmart
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.