Qu'est-ce qui a changé l'affichage de la liste du Finder dans Lion pour rendre «Calculer toutes les tailles» exponentiellement plus rapide?

10

Depuis bien avant l'arrivée de Mac OS X, nous avons pu demander au Finder de calculer toutes les tailles afin de déterminer la somme totale de l'espace de taille de fichier lisible contenu dans chaque dossier pour la fenêtre du Finder en question.

Finder - vue liste - afficher les options d'affichage - Calculer toutes les tailles

J'ai testé le dimensionnement de la vue Liste des dossiers sur plusieurs Mac où peu importe si un SSD est présent ou non, mais Lion est si rapide à calculer les tailles, je suis curieux de savoir s'il existe une nouvelle structure de données de mise en cache ou si le Finder utilise le les informations de métadonnées de Spotlight ou d'une base de données similaire pour accélérer considérablement ce calcul.

lion finder performance

— bmike
source

1

Où avez-vous eu cette fenêtre? Basé sur le bouton "Utiliser comme valeurs par défaut" en bas, il ressemble à la fenêtre "Afficher les options d'affichage" (<kbd> ⌘J </kbd>), mais je n'ai rien pu afficher dans la section inférieure.

— Cajunluke

1

@CajunLuke, vous devez changer la vue de votre fenêtre en liste avant d'ouvrir la fenêtre "Afficher les options de vue".

— pdd

3

Je n'ai pas observé Lion être plus rapide dans le calcul des tailles de dossier (et de package / bundle) lors de la première fois qu'il calcule les tailles dans un dossier. Cependant, les calculs ultérieurs dans le même dossier semblent être beaucoup plus rapides.

Une partie de la rapidité perçue peut être que le Finder affichera immédiatement les tailles précédemment calculées en texte gris pendant qu'il recalcule les tailles de dossier, plutôt que d'afficher "-" jusqu'à ce qu'il soit calculé. Une fois la taille d'un dossier recalculée, le nombre est mis à jour (si la taille a changé) et devient noir.

Étant donné que le Finder met en cache de façon visible les tailles de dossier précédemment calculées, il est possible qu'il recalcule uniquement les tailles des dossiers qui ont changé depuis le dernier calcul.

— joelseph
source

Je pense que c'est le nœud du problème. La mise en cache est bien meilleure et les résultats partiels ou périmés sont affichés de manière incrémentielle. Je ne peux pas dire si l'algorithme est modifié pour remplir les données qui sont en vue, mais le cache seul semble être la réponse à mon plaisir avec la façon dont il fonctionne dans la pratique maintenant.

— bmike

Après quelques mois d'observation attentive, vous avez tout à fait raison. Le mécanisme de mise en cache est maintenant si bon que sur les Mac que j'utilise depuis un certain temps, ces données sont presque toujours correctes et instantanées. Ce n'est que sur un nouveau mac peu de temps après la réinstallation ou la confédération que la vitesse la plus ancienne est visible car le système d'exploitation doit collecter entièrement les informations.

— bmike

7

Avant Lion, la colonne Taille du fichier dans Finder.app afficherait la taille requise par chaque fichier sur le disque dur, pas la taille exacte du fichier. Par exemple, les fichiers de 1 octet étaient affichés sous forme de 4 Ko car ils occupent en fait 4 Ko d'espace sur un système au format HFS. Il n'y avait pas de moyen facile de voir la taille réelle du fichier de 1 octet, à part ouvrir Fichier ›Obtenir des informations (ou utiliser une autre application, comme Terminal.app puis utiliser ls -lsa, ou un remplacement Finder.app comme TotalFinder.app ).

(Retour dans la journée, je l' ai signalé comme bug 8926275 sur bugreport.apple.com .)

À partir de Lion, ce comportement a été corrigé et la colonne Taille du fichier affichera désormais la taille exacte du fichier pour chaque fichier plutôt que la taille qu'il alloue sur le disque dur (qui dépend de toute façon du système de fichiers).

Étant donné que ces tailles sont les mêmes nombres que vous obtiendriez du lsbinaire dans Terminal, elles sont beaucoup plus efficaces à calculer.

— Mathias Bynens
source

1

C'est aussi un détail génial. Au fur et à mesure que les SSD deviennent plus répandus et que le stockage devient plus sophistiqué avec les instantanés, je suppose que cela fait longtemps que vous ne devez plus vous soucier de l'espace occupé par une instance spécifique d'un fichier et vous soucier de la taille logique des fichiers plutôt que physique.

— bmike

Je ne comprends pas ça. Comment est-ce plus efficace? Un seul stat(2)appel n'est-il pas responsable de la récupération des deux numéros? Et ls(1)ne montre pas du tout la taille réelle des bundles / packages / dossiers, donc je n'ai aucune idée pourquoi c'est pertinent.

— Ken

@Ken lsmontre très bien la taille des fichiers pour les fichiers normaux. statpeut faire de même pour un seul fichier. Mon point est que le «travail supplémentaire» nécessaire pour calculer la taille des bundles / packages / dossiers n'est désormais nécessaire que pour les bundles / packages / dossiers, et non plus pour les fichiers normaux.

— Mathias Bynens

Mathias: Oui, lsmontre la taille des fichiers pour les fichiers normaux, pas les bundles (c'est ce que j'ai dit). Il le fait en appelant stat. Quel «travail supplémentaire» était requis auparavant pour les fichiers normaux? Un seul statappel renvoie à la fois les blocs ( st_blocks) et les octets ( st_size).

— Ken

1

Je ne serais pas surpris s'ils utilisaient les métadonnées Spotlight pour mettre en cache la taille des fichiers. Si vous utilisez déjà FSEvents pour suivre toutes les modifications du système de fichiers et (éventuellement) Time Machine pour sauvegarder toutes ces modifications, le coût supplémentaire de calcul et de stockage des tailles de fichier agrégées est négligeable.

— Cajunluke
source

Je vais voir si je peux obtenir fs_events pour renverser les haricots s'il s'agit de métadonnées ou autrement. J'adorerais lire des données sur les projecteurs - mais je n'ai pas encore de preuves directes.

— bmike

1

À partir d'OS X Lion, Apple a ajouté une base de données SQLite que le système d'exploitation utilise pour le suivi des fichiers dans les fonctionnalités système telles que Spotlight. L'interrogation à partir d'une base de données SQLite plutôt que l'inspection du système de fichiers à chaque fois est plus que probablement la cause de l'amélioration des performances. La revue OS X Lion de John Siracusa explique en détail les modifications apportées au système de fichiers dans Lion. En particulier, vous trouverez ici une explication sur la nouvelle base de données SQLite.

J'espère que cela t'aides.

— Christian Correa
source

C'est un très bon lien, mais la base de données SQLite apparaît sur tous mes macs pour suivre uniquement les documents qui ont des versions qui est un petit sous-ensemble du total des fichiers sur le disque. Si vous pouvez trouver un lien vers une base de données qui stocke toutes les tailles de fichiers, ce serait pour le moins intéressant car le système de fichiers est déjà une base de données pour ce faire, non?

— bmike