Що змінило подання списку Finder у Леві, щоб зробити "Обчислити всі розміри" експоненціально швидше?

10

З моменту появи на сцені Mac OS X, ми змогли попросити Finder обчислити всі розміри , щоб визначити загальну кількість читабельного простору розміру файлу, що міститься у кожній папці, для відповідного вікна Finder.

Finder - перегляд списку - показати параметри подання - Обчислити всі розміри

Я перевірив розмір папок списку на декількох Macs, де не важливо, присутній чи ні SSD, але Lion настільки швидкий при обчисленні розмірів, мені цікаво, чи є якась нова структура даних кешування або якщо Finder використовує інформація про метадані з Spotlight або подібної бази даних, щоб пришвидшити цей розрахунок.

lion finder performance

— bmike
джерело

1

Де ти взяв це вікно? На основі кнопки "Використовувати як за замовчуванням" внизу це виглядає як вікно "Показати параметри перегляду" (<kbd> ⌘J </kbd>), але я не зміг нічого показати в нижньому розділі.

— Cajunluke

1

@CajunLuke вам потрібно переключити перегляд вікна до списку перед відкриттям вікна "Показати параметри подання".

— пдд

3

Я не спостерігав, щоб Лев був швидшим при обчисленні розмірів папок (і пакунків / пакетів) під час першого розрахунку розмірів у папці. Однак наступні обчислення в одній папці здаються набагато швидшими.

Частина сприйнятої швидкості може полягати в тому, що Finder негайно покаже раніше обчислені розміри сірим текстом, поки він перерахує розміри папок, а не покаже "-", поки не буде обчислено. Після перерахунку розміру папки номер оновиться (якщо розмір змінився) і стане чорним.

Оскільки Finder помітно кешує раніше обчислені розміри папок, можливо, він перераховує розміри лише для папок, які змінилися з моменту останнього обчислення.

— Йольсеф
джерело

Я думаю, що це суть питання. Кешування набагато краще, і часткові або несвіжі результати відображаються поступово. Я не можу сказати, чи алгоритм налаштований на заповнення даних, які переглядаються, але кешування кеші, здається, є відповіддю на моє задоволення від того, як він працює на практиці зараз.

— bmike

Через кілька місяців уважного спостереження за цим ви абсолютно правильні. Механізм кешування зараз настільки гарний, що в Macs, який я використовував деякий час, ці дані майже завжди є правильними та миттєвими. Тільки на новому mac невдовзі після перевстановлення чи конфедерації помітніша старша швидкість, оскільки ОС повинна збирати інформацію повністю.

— bmike

7

Перед Левом, стовпець «Розмір файлу» в Finder.app відображав би розмір, необхідний кожному файлу на жорсткому диску, а не точний розмір файлу. Наприклад, 1 байт-файли відображалися у форматі 4 КБ, оскільки вони фактично займають 4 КБ місця у системі, форматованій HFS. Не було простого способу побачити фактичний розмір файлу в 1 байт, крім відкриття Файл ›Отримати інформацію (або використовуючи інший додаток, наприклад, Terminal.app, а потім за допомогою ls -lsa, або Заміну Finder.app, як TotalFinder.app ).

(Назад в день, я повідомив про це , як помилка 8926275 на bugreport.apple.com .)

Станом на Lion, ця поведінка була виправлена, і стовпець Розмір файлу тепер покаже точний розмір файлу для кожного файлу, а не розмір, який він виділяє на жорсткому диску (який все одно залежить від файлової системи).

Оскільки ці розміри є однаковими числами, які ви отримаєте з lsдвійкового в Терміналі, їх обчислити набагато ефективніше.

— Матіас Байненс
джерело

1

Це також дивовижна деталь. У міру того, як SSD стає більш поширеним, а зберігання стає все більш досконалим із знімками, я вважаю, що давно минуло, тому що перестати турбуватися про те, скільки місця займає конкретний екземпляр файлу, і просто перейматися логічним розміром файлів на відміну від фізичного.

— bmike

Я цього не розумію. Наскільки це ефективніше? Чи не один stat(2)виклик відповідає за отримання обох номерів? І ls(1)зовсім не показує фактичний розмір пакетів / пакунків / папок, тому я не маю поняття, чому це актуально.

— Кен

@Ken lsпоказує розміри файлів просто для звичайних файлів. statможна зробити те ж саме для одного файлу. Думаю, що "додаткова робота", необхідна для обчислення розмірів пакетів / пакунків / папок, тепер потрібна лише для пакетів / пакетів / папок, а не для звичайних файлів.

— Mathias Bynens

Матіас: Так, lsпоказує розміри файлів для звичайних файлів, а не пакетів (це я вже сказав). Це роблять, зателефонувавши stat. Яка «додаткова робота» була потрібна для звичайних файлів раніше? Один statвиклик повертає і блоки ( st_blocks), і байти ( st_size).

— Кен

1

Я не був би здивований, якби вони використовували метадані Spotlight для кешування розмірів файлів. Якщо ви вже використовуєте FSEvent для відстеження всіх змін у файловій системі та (можливо) Time Machine для резервного копіювання всіх цих змін, додаткова вартість обчислення та зберігання сукупних розмірів файлів незначна.

— Каджунлук
джерело

Я побачу, чи зможу я отримати fs_events для розсипання квасолі, якщо це метадані чи іншим чином. Мені б хотілося прочитати дані про прожектор - але поки немає прямих доказів.

— bmike

1

Починаючи з OS X Lion, Apple додала базу даних SQLite, яку ОС використовує для відстеження файлів у функціях системи, таких як Spotlight. Запит із бази даних SQLite, а не перевірка файлової системи кожен раз, швидше за все, є причиною підвищення продуктивності. Огляд ОС OS X Lion Джона Сіракузи пояснює глибоко зміни файлової системи в Lion. Зокрема, тут ви знайдете пояснення щодо нової бази даних SQLite.

Сподіваюсь, це допомагає.

— Крістіан Коррея
джерело

Це дуже приємне посилання, однак база даних SQLite з'являється у всіх моїх Mac-файлах лише для відстеження документів, які мають версії, що є невеликим підмножиною загальної кількості файлів на диску. Якщо ви можете знайти посилання на базу даних, яка зберігає всі розміри файлів, це було б щонайменше цікаво, оскільки для цього файлова система вже є базою даних, ні?

— bmike