Что изменило представление списка Finder в Lion, чтобы сделать «Расчет всех размеров» экспоненциально быстрее?


10

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

Finder - просмотр списка - показать параметры просмотра - рассчитать все размеры

Я протестировал размер представления списка в папках на нескольких компьютерах Mac, где не имеет значения, присутствует ли SSD или нет, но Lion очень быстро вычисляет размеры. Мне интересно, есть ли какая-то новая структура данных кэширования или Finder использует информация метаданных из Spotlight или аналогичной базы данных, чтобы ускорить этот расчет.


1
Где ты взял это окно? На основании кнопки «Использовать по умолчанию» внизу, она выглядит как окно «Показать параметры просмотра» (<kbd> ⌘J </ kbd>), но я не смог ничего показать в нижней части.
Cajunluke

1
@CajunLuke, вам нужно переключить вид окна в список, прежде чем открывать окно «Показать параметры просмотра».
pdd

Ответы:


3

Я не заметил, чтобы Lion быстрее вычислял размеры папок (и package / bundle) в первый раз, когда он вычисляет размеры в папке. Тем не менее, последующие вычисления в той же папке, кажется, гораздо быстрее.

Частично воспринимаемая быстрота может заключаться в том, что Finder немедленно покажет ранее рассчитанные размеры в сером тексте, пока он пересчитывает размеры папок, вместо того, чтобы показывать «-», пока он не будет рассчитан. После пересчета размера папки номер обновится (если размер изменился) и станет черным.

Поскольку Finder заметно кэширует ранее рассчитанные размеры папок, возможно, он только пересчитывает размеры папок, которые изменились с момента последнего вычисления.


Я думаю, что это суть проблемы. Кэширование намного лучше, а частичные или устаревшие результаты отображаются постепенно. Я не могу сказать, настроен ли алгоритм для заполнения данных, которые находятся в поле зрения, но, похоже, одно только кеширование - ответ на мое удовольствие от того, как он работает на практике.
bmike

После нескольких месяцев наблюдения за этим вы совершенно правы. Механизм кэширования теперь настолько хорош, что на компьютерах Mac, которые я использовал некоторое время, эти данные почти всегда правильные и мгновенные. Только на новом Mac вскоре после переустановки или конфедерации заметна более старая скорость, поскольку ОС должна собирать информацию полностью.
bmike

7

До Lion в столбце «Размер файла» в 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может сделать то же самое для одного файла. Я хочу сказать, что «дополнительная работа», необходимая для расчета размеров пакетов / пакетов / папок, теперь необходима только для пакетов / пакетов / папок, а не для обычных файлов.
Матиас Биненс

Матиас: Да, lsпоказывает размеры файлов для обычных файлов, а не для пакетов (это то, что я сказал). Это делается по телефону stat. Какая «дополнительная работа» требовалась для обычных файлов ранее? Один statвызов возвращает оба блока ( st_blocks) и байты ( st_size).
Кен

1

Я не удивлюсь, если они используют метаданные Spotlight для кэширования размеров файлов. Если вы уже используете FSEvents для отслеживания всех изменений в файловой системе и (потенциально) Time Machine для резервного копирования всех этих изменений, дополнительные затраты на вычисление и хранение совокупных размеров файлов незначительны.


Я посмотрю, смогу ли я заставить fs_events пролить бобы, если это метаданные или нет. Я хотел бы прочитать данные центра внимания - но у меня пока нет прямых доказательств.
bmike

1

Начиная с OS X Lion, Apple добавила базу данных SQLite, которую ОС использует для отслеживания файлов в системных функциях, таких как Spotlight. Запросы из базы данных SQLite, а не проверка файловой системы каждый раз, скорее всего, являются причиной повышения производительности. Обзор OS X Lion Джона Сиракузы подробно объясняет изменения файловой системы в Lion. В частности, здесь вы найдете объяснение новой базы данных SQLite.

Надеюсь это поможет.


Это очень хорошая ссылка, однако база данных SQLite появляется на всех моих маках для отслеживания только тех документов, которые имеют версии, составляющие небольшое подмножество общих файлов на диске. Если вы можете найти ссылку на базу данных, в которой хранятся файлы всех размеров, было бы интересно, мягко говоря, поскольку файловая система уже является базой данных для этого, нет?
bmike
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.