Was hat die Finder-Listenansicht in Lion geändert, um "Alle Größen berechnen" exponentiell schneller zu machen?

Lange bevor Mac OS X auf den Markt kam, konnten wir den Finder auffordern, alle Größen zu berechnen , um die Gesamtsumme des lesbaren Speicherplatzes für Dateien zu bestimmen, der in jedem Ordner für das betreffende Finder-Fenster enthalten ist.

Finder - Listenansicht - Ansichtsoptionen anzeigen - Alle Größen berechnen

Ich habe die Größenanpassung der Listenansicht von Ordnern auf mehreren Macs getestet, bei denen es keine Rolle spielt, ob eine SSD vorhanden ist oder nicht, aber Lion berechnet Größen so schnell, dass ich neugierig bin, ob es eine neue Caching-Datenstruktur gibt oder ob der Finder die verwendet Metadateninformationen aus Spotlight oder einer ähnlichen Datenbank, um diese Berechnung enorm zu beschleunigen.

Wo hast du das Fenster her? Basierend auf der Schaltfläche "Als Standard verwenden" unten sieht es aus wie das Fenster "Ansichtsoptionen anzeigen" (<kbd>⌘J</kbd>), aber ich konnte im unteren Abschnitt nichts anzeigen.
@CajunLuke Sie müssen Ihre Fensteransicht auf Liste umstellen, bevor Sie das Fenster "Ansichtsoptionen anzeigen" öffnen.

Antworten (4)

Ich habe nicht beobachtet, dass Lion bei der Berechnung von Ordner- (und Paket-/Bündel-) Größen beim ersten Mal, wenn es Größen in einem Ordner berechnet, schneller ist. Nachfolgende Berechnungen im selben Ordner scheinen jedoch viel schneller zu sein.

Ein Teil der wahrgenommenen Schnelligkeit kann darin bestehen, dass der Finder die zuvor berechneten Größen sofort in grauem Text anzeigt, während er die Ordnergrößen neu berechnet, anstatt „--“ anzuzeigen, bis sie berechnet wurden. Nachdem die Größe eines Ordners neu berechnet wurde, wird die Zahl aktualisiert (wenn sich die Größe geändert hat) und schwarz.

Da der Finder zuvor berechnete Ordnergrößen sichtbar zwischenspeichert, ist es möglich, dass er nur Größen für Ordner neu berechnet, die sich seit der letzten Berechnung geändert haben.

Nachdem Sie dies einige Monate lang genau beobachtet haben, haben Sie vollkommen recht. Der Caching-Mechanismus ist jetzt so gut, dass diese Daten auf den Macs, die ich seit einiger Zeit verwende, fast immer korrekt und sofort verfügbar sind. Nur auf einem neuen Mac kurz nach der Neuinstallation oder Confederation macht sich die ältere Geschwindigkeit bemerkbar, da das OS die Informationen vollständig sammeln muss.

Vor Lion zeigte die Spalte Dateigröße in Finder.app die Größe an, die jede Datei auf der Festplatte benötigt, nicht die genaue Dateigröße. Beispielsweise wurden 1-Byte-Dateien als 4 KB angezeigt, da sie auf einem HFS-formatierten System tatsächlich 4 KB Speicherplatz beanspruchen. Es gab keine einfache Möglichkeit, die tatsächliche Dateigröße von 1 Byte zu sehen, außer File › Get Info zu öffnen (oder eine andere App zu verwenden, wie Terminal.app und dann ls -lsa, oder einen Finder.app-Ersatz wie TotalFinder.app ).

(Früher habe ich dies als Fehler 8926275 auf bugreport.apple.com gemeldet .)

Ab Lion wurde dieses Verhalten korrigiert, und die Spalte Dateigröße zeigt jetzt die genaue Dateigröße für jede Datei an, anstatt die Größe, die sie auf der Festplatte zuweist (die ohnehin vom Dateisystem abhängt).

Da es sich bei diesen Größen um dieselben Zahlen handelt, die Sie aus der lsBinärdatei in Terminal erhalten würden, sind sie viel effizienter zu berechnen.

Das ist auch ein tolles Detail. Mit der zunehmenden Verbreitung von SSDs und der immer ausgefeilteren Speicherung von Snapshots ist es meiner Meinung nach längst vorbei, sich keine Gedanken mehr darüber zu machen, wie viel Speicherplatz eine bestimmte Instanz einer Datei belegt, sondern sich nur noch Gedanken über die logische Größe von Dateien im Gegensatz zur physischen zu machen.
Ich verstehe das nicht. Wie ist das effizienter? Ist nicht ein einziger stat(2)Anruf dafür verantwortlich, beide Nummern abzurufen? Und ls(1)zeigt überhaupt nicht die tatsächliche Größe von Bündeln/Paketen/Ordnern an, daher habe ich keine Ahnung, warum das relevant ist.
@Ken lszeigt Dateigrößen für normale Dateien an. statkann dasselbe für eine einzelne Datei tun. Mein Punkt ist, dass die „zusätzliche Arbeit“, die zum Berechnen der Bündel-/Paket-/Ordnergrößen erforderlich ist, jetzt nur noch für Bündel/Pakete/Ordner erforderlich ist, nicht mehr für normale Dateien.
Mathias: Ja, lszeigt Dateigrößen für normale Dateien, nicht Bundles (das habe ich gesagt). Dies geschieht durch Aufrufen von stat. Welche „Mehrarbeit“ war bisher für reguläre Dateien erforderlich? Ein einzelner statAufruf gibt sowohl Blöcke ( st_blocks) als auch Bytes ( st_size) zurück.

Beginnend mit OS X Lion hat Apple eine SQLite-Datenbank hinzugefügt, die das Betriebssystem für die Dateiverfolgung in Systemfunktionen wie Spotlight verwendet. Das Abfragen aus einer SQLite-Datenbank, anstatt jedes Mal das Dateisystem zu inspizieren, ist mehr als wahrscheinlich die Ursache für die Leistungsverbesserung. Der OS X Lion-Review von John Siracusa erklärt ausführlich die Änderungen am Dateisystem in Lion. Insbesondere finden Sie hier eine Erläuterung zur neuen SQLite-Datenbank.

Hoffe das hilft.

Dies ist ein sehr netter Link, aber die SQLite-Datenbank erscheint auf allen meinen Macs, um nur Dokumente zu verfolgen, die Versionen haben, was eine kleine Teilmenge der gesamten Dateien auf dem Laufwerk ist. Wenn Sie einen Link zu einer Datenbank finden können, die alle Dateigrößen speichert, wäre das gelinde gesagt interessant, da das Dateisystem bereits eine Datenbank ist, um dies zu tun, oder?

Ich wäre nicht überrascht, wenn sie Spotlight-Metadaten verwenden würden, um Dateigrößen zwischenzuspeichern. Wenn Sie bereits FSEvents verwenden, um alle Änderungen im Dateisystem zu verfolgen, und (möglicherweise) Time Machine, um all diese Änderungen zu sichern, sind die zusätzlichen Kosten für die Berechnung und Speicherung der aggregierten Dateigrößen vernachlässigbar.

Ich werde sehen, ob ich fs_events dazu bringen kann, die Bohnen zu verschütten, ob es sich um Metadaten oder etwas anderes handelt. Ich würde gerne Spotlight-Daten lesen – habe aber noch keine direkten Beweise.