Apa yang telah mengubah tampilan daftar Finder di Lion untuk menjadikan "Hitung semua ukuran" secara eksponensial lebih cepat?


10

Sejak jauh sebelum Mac OS X hadir, kami dapat meminta Finder untuk Menghitung semua ukuran untuk menentukan jumlah total ruang ukuran file yang dapat dibaca yang terdapat di setiap folder untuk jendela Finder yang dimaksud.

Finder - tampilan daftar - tampilkan opsi tampilan - Hitung semua ukuran

Saya telah menguji ukuran tampilan daftar folder pada beberapa Mac di mana tidak masalah jika SSD hadir atau tidak, tapi Lion begitu cepat dalam menghitung ukuran Saya ingin tahu apakah ada beberapa struktur data caching baru atau jika Finder menggunakan informasi metadata dari Spotlight atau database serupa untuk mempercepat perhitungan ini.


1
Di mana Anda mendapatkan jendela itu? Berdasarkan tombol "Use as Defaults" di bagian bawah, sepertinya jendela "Show View Options" (<kbd> ⌘J </kbd>), tapi saya tidak bisa mendapatkan apa pun untuk ditampilkan di bagian bawah.
Cajunluke

1
@CajunLuke Anda perlu mengalihkan tampilan jendela ke daftar sebelum membuka jendela "Tampilkan Pilihan".
pdd

Jawaban:


3

Saya belum mengamati Lion lebih cepat dalam menghitung ukuran folder (dan paket / bundel) selama pertama kali menghitung ukuran dalam folder. Namun, perhitungan selanjutnya dalam folder yang sama tampaknya jauh lebih cepat.

Bagian dari kecepatan yang dirasakan mungkin bahwa Finder akan segera menampilkan ukuran yang sebelumnya dihitung dalam teks abu-abu saat menghitung ulang ukuran folder, daripada menampilkan "-" sampai dihitung. Setelah ukuran folder dihitung ulang, nomor akan diperbarui (jika ukurannya berubah) dan berubah menjadi hitam.

Karena Finder mengamati cache ukuran folder yang sebelumnya dihitung, mungkin saja itu hanya menghitung ulang ukuran folder yang telah berubah sejak terakhir kali dihitung.


Saya pikir ini adalah inti dari masalah ini. Caching jauh lebih baik dan hasil parsial atau basi ditampilkan secara bertahap. Saya tidak tahu apakah algoritme di-tweak untuk mengisi data yang sedang dilihat, tetapi cache itu sendiri tampaknya menjadi jawaban untuk kesenangan saya dengan cara kerjanya dalam praktiknya sekarang.
bmike

Setelah beberapa bulan mengamati ini dengan seksama, Anda sepenuhnya benar. Mekanisme caching sekarang sangat bagus sehingga pada Mac yang saya gunakan untuk sementara waktu, data ini hampir selalu benar dan seketika. Hanya pada mac baru tidak lama setelah penginstalan ulang atau konfederasi adalah kecepatan yang lebih lama terlihat karena OS harus mengumpulkan informasi sepenuhnya.
bmike

7

Sebelum Lion, kolom Ukuran File di Finder.app akan menampilkan ukuran yang dibutuhkan setiap file pada hard disk, bukan ukuran file yang tepat. Sebagai contoh, file 1 byte ditampilkan sebagai 4 KB karena mereka sebenarnya mengambil ruang 4 KB pada sistem yang diformat HFS. Tidak ada cara mudah untuk melihat ukuran file aktual 1 byte, selain membuka File ›Get Info (atau menggunakan aplikasi yang berbeda, seperti Terminal.app dan kemudian menggunakan ls -lsa, atau penggantian Finder.app seperti TotalFinder.app ).

(Kembali pada hari itu, saya melaporkan ini sebagai bug 8926275 di bugreport.apple.com .)

Pada Lion, perilaku ini telah diperbaiki, dan kolom Ukuran File sekarang akan menunjukkan ukuran file yang tepat untuk setiap file daripada ukuran yang dialokasikan pada hard disk (yang tergantung pada sistem file tetap).

Karena ukuran ini adalah angka yang sama dengan yang Anda dapatkan dari lsbiner di Terminal, mereka jauh lebih efisien untuk dihitung.


1
Ini juga detail yang luar biasa. Ketika SSD menjadi lebih lazim dan penyimpanan menjadi lebih canggih dengan foto-foto, saya kira itu sudah lama karena berhenti khawatir tentang berapa banyak ruang yang ditempati oleh contoh file tertentu dan hanya khawatir tentang ukuran logis file yang bertentangan dengan fisik.
bmike

Saya tidak mengerti ini. Bagaimana itu lebih efisien? Bukankah satu stat(2)panggilan bertanggung jawab untuk mengambil kedua nomor? Dan ls(1)tidak menunjukkan ukuran sebenarnya dari bundel / paket / folder sama sekali, jadi saya tidak tahu mengapa itu relevan.
Ken

@ Ken lsmenunjukkan ukuran file dengan baik untuk file biasa. statdapat melakukan hal yang sama untuk satu file. Maksud saya adalah bahwa "kerja ekstra" yang diperlukan untuk menghitung bundel / paket / ukuran folder sekarang hanya diperlukan untuk bundel / paket / folder, bukan untuk file biasa lagi.
Mathias Bynens

Mathias: Ya, lsmenunjukkan ukuran file untuk file biasa, bukan bundel (itulah yang saya katakan). Ini melakukan ini dengan menelepon stat. "Kerja ekstra" apa yang diperlukan untuk file biasa sebelumnya? statPanggilan tunggal mengembalikan kedua blok ( st_blocks) dan byte ( st_size).
Ken

1

Saya tidak akan terkejut jika mereka menggunakan metadata Spotlight untuk menyimpan ukuran file cache. Jika Anda sudah menggunakan FSEvents untuk melacak semua perubahan dalam sistem file dan (berpotensi) Time Machine untuk mendukung semua perubahan itu, biaya tambahan untuk menghitung dan menyimpan ukuran file agregat dapat diabaikan.


Saya akan melihat apakah saya bisa meminta fs_events untuk menumpahkan kacang jika metadata atau lainnya. Saya ingin sekali membaca data sorotan - tetapi belum memiliki bukti langsung.
bmike

1

Dimulai dengan OS X Lion, Apple telah menambahkan database SQLite yang OS gunakan untuk pelacakan file dalam fitur sistem seperti Spotlight. Permintaan dari database SQLite daripada memeriksa sistem file setiap kali lebih besar kemungkinan menjadi penyebab peningkatan kinerja. Ulasan OS X Lion dari John Siracusa menjelaskan secara mendalam perubahan pada sistem file di Lion. Khususnya, di sini Anda akan menemukan penjelasan tentang database SQLite baru.

Semoga ini membantu.


Ini adalah tautan yang sangat bagus, namun basis data SQLite muncul di semua mac saya untuk hanya melacak dokumen yang memiliki versi yang merupakan subset kecil dari total file pada drive. Jika Anda dapat menemukan tautan ke database yang menyimpan semua ukuran file, itu akan menarik untuk sedikitnya karena sistem file sudah menjadi database untuk melakukan ini, bukan?
bmike
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.