1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Panther (10)







Les performances du Finder

Les versions précédentes du Finder de Mac OS X, souffraient d'un mauvais cas le la maladie de la roulette multicolore. Ce curseur rotatif coloré apparaît quand une application s'est arrêtée de gérer les évènements pendant quelques secondes. Sous Jaguar, et auparavant, le Finder pouvait cesser complètement de répondre dans de nombreuses situations courantes, dont la plupart impliquaient l'accès aux ressources du réseau. Panther les réduit de façon substantielle, mais n'a pas éliminé complètement ce problème.

Les volumes en réseau peuvent être montés à l'aide de l'item de menu "Se connecter..." sous Jaguar, mais Panther autorise aussi la navigation sur le réseau par l'intermédiaire de l'icône "Réseau" précédemment sous utilisée au somment de la hiérarchie du Finder. Le réseau sous Windows repose maintenant sur la version 3 de Samba, beaucoup plus puissante. Malheureusement, l'implémentation incomplète de FTP dans le Finder ne permet pas encore les chargements FTP, et se comporte comme un chien dans un jeu de quilles, par comparaison avec des applications FTP tierces.

La plupart des reproches sur la performance du Finder de Mac OS X tournent autour des sujets évoqués plus haut, et en particulier le réseau. Mais il y a un autre aspect, plus simple, de la performance du gestionnaire de fichiers qui a été éclipsée par ces problèmes plus sérieux. Dans le temps où Mac OS X n'était qu'un ensemble de boîtes colorées sur une diapo et quelques milliers de rumeurs sur le web, le Finder de la nouvelle génération du système d'exploitation du Mac a été conçu comme une machine à manipuler les fichiers, capable de gérer des dossiers et des volumes avec des milliers et des milliers de fichiers sans reprendre son souffle.

La réalité du Finder original de Mac OS X fut que la simple tentative d'ouvrir une fenêtre contenant quelques milliers de fichiers provoquait un blocage complet de l'application, et un peu plus de temps passé avec votre vieille amie, la roulette muticolore. A la fin, l'action pouvait reprendre, mais que Dieu vous aide si ce dossier était sur un volume du réseau. Vous pouviez tout aussi bien aller prendre une tasse de café.

Semblablement, la sélection et l'utilisation d'un grand nombre de fichiers et de dossiers était affectée de blocages et de longues attentes. Un clic droit sur une sélection de quelques milliers de fichiers, et vous étiez parti(e) pour un peu de vacances. Essayez de glisser ces mêmes fichiers et vous allez devoir maintenir longtemps le bouton de la souris, en attendant que le Finder recommence à répondre. Ce n'est pas là le Finder évolué, ultra-moderne que nous envisagions tous.

Les choses se sont améliorées régulièrement, et Panther est plus rapide que ses prédécesseurs, quand il gère un grand nombre de fichiers. Mais ce mouvement d'amélioration régulier n'est pas prêt de s'arrêter, au moins à son rythme actuel. La manipulation, ou simplement l'affichage d'un grand nombre de fichiers sont encore plusieurs ordres de grandeur trop lents dans le Finder de Panther, en particulier quand il s'agit de volumes sur le réseau.

Par exemple, j'ai essayé récemment de parcourir une vue en liste de dossier sur un volume SMB partagé contenant environ 2000 fichiers en utilisant le Finder de Panther sur mon G5 dual à 2 GHz. Le serveur était sur le LAN local à 100 Mbps. Cela m'a pris plusieurs minutes d'attente patiente, à déplacer la roulette multicolore dans de petits morceaux de la liste de fichiers, à attendre à chaque fois que le Finder affiche lentement les icônes pour les nouveaux fichiers affichés, avant que le système me permette de continuer.

Le Finder ne me permettait absolument pas de défiler sur des portions "inconnues" de la liste des fichiers avant d'avoir fini d'afficher les icônes des nouveaux fichiers affichés. Ces fichiers étaient tous du même type, et c'était de simples fichiers plats sans fourche de ressource et sans méta-données spécifiques au Mac. Ce n'est qu'après avoir bataillé avec la fenêtre pendant plusieurs minutes que j'ai été finalement capable de glisser la barre de défilement de haut en bas dans un mouvement continu.

Le listing du même répertoire en ligne de commande est presque instantané. On s'attend à un certain impact de l'IUG, mais là, c'est ridicule.

Malheureusement, donner à un navigateur de fichiers en IUG la vitesse de l'éclair est un problème très difficile, plein de cas particuliers, et qui nécessite une optimisation soigneuse. Le Finder de Mac OS X se révèle utiliser un bon nombre de contrôles et de vues standards de Mac OS X. Les améliorations de performance du Finder ont en partie été le résultat d'une optimisation de ces widgets fournis par l'OS.

Mais, alors que l'optimisation des contrôles courants est une tâche importante, qui peut améliorer de façon significative la performance de toutes les applications, certaines applications ont tout simplement des besoins qui excèdent largement ce que des contrôles génériques peuvent fournir. Le Finder est une de ces applications. Soit à l'aide de contrôles complètement nouveaux, soit avec des sous-classements habiles, le Finder a besoin d'implémenter ses vues avec attention, en manipulant des milliers de fichiers et de dossiers facilement, efficacement , et rapidement.

Même dans des situations où les données sous-jacentes sont un facteur limitant de performance (par exemple des disques réseau lents) le Finder doit tout faire pour rester docile, afficher aussi peu ou autant d'information dont il dispose à l'instant, mais ne jamais empêcher l'utilisateur d'interagir avec l'IUG. Des contrôles et des vues constitués par des objets en mémoire et par des structures de données sont mal adaptés à cette tâche.

Indépendamment des autres problèmes de l'interface, j'espère pouvoir un jour afficher, manipuler, et parcourir un grand nombre de fichiers et de dossiers dans le Finder de Mac OS X, avec une confiance aveugle adaptée à un système d'exploitation qui tourne sur une machine multi-gigahertz, avec des Go de RAM. Je regrette, Finder de Panther, mais tu n'es pas encore ce gestionnaire de fichiers.


L'interrogation

Il y a un dernier aspect des performances du Finder qui mérite une mention ici, même si c'est en fait (ou du moins devrait être) un problème d'usage à la base. Comme tout développeur vous le dira, "l'interrogation, c'est mauvais n'est-ce pas ?". L'interrogation (polling) est le fait de tester répétitivement une condition. Un exemple adapté au Finder serait de demander " Y a-t-il de nouveaux fichiers dans ce dossier ?, y a-t-il de nouveaux fichiers dans ce dossier ?, y a-t-il de nouveaux fichiers dans ce dossier?, y a-t-il de nouveaux fichiers dans ce dossier?, y a-t-il de nouveaux fichiers dans ce dossier?" et ainsi de suite, à des intervalles réguliers.

Inutile de dire que ce n'est pas le mieux pour les cycles CPU, puisque la réponse sera la même à peu près tout le temps : "il n'y a pas de nouveaux fichiers dans ce dossier, et maintenant, laisse moi tranquille". D'accord, c'est moi qui ai rajouté la fin, mais c'est adapté. L'interrogation est en fait mauvaise.

Mais si vous pensez à la situation décrite ci-dessus, la capacité de réaction du Finder semble dépendre de la fréquence des interrogations effectuées. Disons que vous téléchargez un fichier sur votre ordinateur en utilisant un navigateur web. Si le Finder interroge le dossier de l'ordinateur toutes les dix secondes, ce fichier ne se différenciera pas pendant en moyenne 5 secondes. C'est à peine "réactif".

Une autre alternative est simplement d'utiliser les vues du Finder quand l'utilisateur (ou un programme autre) demande au Finder de le faire. Cela élimine entièrement une interrogation coûteuse. Et mieux, si les applications notifient loyalement le Finder de tout changement qu'elles opèrent sur le système de fichiers, il n'y aura pas du tout de retard entre la création du fichier et son apparition dans le Finder. C'est le système qu'Apple a choisi pour le Finder de Mac OS X, et cela semble le bon choix.

Dans la pratique, cependant, toutes les applications ne notifient pas correctement le Finder des changements qu'elles opèrent sur le système de fichier. Un utilitaire en ligne de commande du monde FreeBSD est le pire scénario. On ne peut certainement pas s'attendre à avoir du code spécifique au Mac pour envoyer des notifications au Finder. Les fichiers créés par ces applications "non coopératives" (du point de vue du Finder) ne s'afficheront simplement pas du tout dans le Finder. Affreux !

Le Finder de Mac OS X a résolu ce problème par l'interrogation, seulement quand l'utilisateur commence à faire quelque chose avec un dossier particulier. Par exemple, un fichier copié sur le bureau avec la ligne de commande "cp" n'apparaîtra pas tant que l'utilisateur n'active pas le Finder en cliquant sur le bureau, sur une fenêtre du Finder, ou sur l'icône du Finder dans le Dock, etc...

Il semble maintenant que nous avons abordé toutes les bases. Il n'y a pas d'interrogation du tout, et le Finder est raisonnablement tenu au courant de toute sorte de changement dans le système de fichiers. Mais il reste des problèmes. Le plus frustrant, c'est que les fenêtres de vues en liste triées ont la fâcheuse habitude de se mettre à jour juste au moment où vous attrapez un fichier dedans. Si vous n'y faites pas assez attention, la fenêtre va réordonner son contenu (à cause d'un fichier nouvellement ajouté, effacé ou modifié), et remplace le fichier que vous vouliez saisir par un autre. Il est beaucoup trop facile de vous faire piéger de cette façon notamment en effaçant un fichier.

Cette situation -interrogation contre réactivité- est quelque peu le signe de ce que j'ai toujours considéré comme un problème dans la direction qu'a pris le développement de Mac OS X. D'accord, l'interrogation est mauvaise, mais son usage est classique. Mac OS est le symbole d'un système de valeurs qui place l'expérience utilisateur en premier. "Comment pouvons nous réaliser cela ? " Sous Mac OS X, il me semble que la première priorité a été de faire ce qui était le plus efficace, puis d'essayer de fournir la meilleure interface utilisateur qu'on puisse facilement implémenter sur ces bases. La chaussure est sur le mauvais pied dans un tel système.

Il peut sembler contradictoire de souffler le froid et le chaud sur les mauvaises performances d'une part, puis d'exiger que l'expérience de l'utilisateur soit prioritaire sur toutes les autres considérations d'autre part, mais la performance fait partie d'une bonne expérience utilisateur. L'attention sur l'utilisateur et la performance prendra principalement soin d'elle même... oui, ce qui signifie à l'occasion qu'il vous faudra implémenter de nouvelles caractéristiques de l'OS au service de l'expérience utilisateur que vous espérez procurer. Mais le résultat final sera un meilleur système dans l'ensemble. Quartz est un exemple de ce principe en action, mais le Finder de Mac OS X semble être un résultat du système de valeurs opposé.

Alors, revenons à la réactivité du Finder en ce qui concerne les modifications du système de fichiers. Commençons par les prémices selon lesquels le Finder doit toujours fournir à l'utilisateur une vue parfaitement consistante du système de fichiers. Ceci est essentiel pour maintenir l'illusion d'une manipulation directe. A l'évidence, l'interrogation pêche encore, particulièrement s'il faut interroger plusieurs fois par seconde pour satisfaire les objectifs de réactivité. Que pouvons-nous faire de mieux ?

Et si le responsabilité de traquer les modifications du système de fichiers et de notifier les parties intéressées était déplacée des applications vers le noyau du système d'exploitation lui-même ? Comme toute Entrée/Sortie de fichier local transite par le le noyau, de toute façon, il sait quand, où, et comment chaque changement s'opère. Tout cela sans interrogation, bien sûr. Il n'y a aucun besoin d'interrogation quand vous faites vous-même toutes les modifications.

Et bien, c'est le jour de chance d'Apple. Confrontés à un problème similaire -comment traquer les modifications sans interrogation coûteuse et inefficace-, les développeurs diligents de FreeBSD ont créé un utilitaire générique au niveau de l'OS pour des notifications asynchrones d'évènements. Il s'appelle kqueue et vous pouvez voir tout ce qui le concerne dans ce fichier PDF. Comme Panther s'est synchronisé avec FreeBSD 5, il inclut le support de kqueue. Maintenant, tout ce que le Finder a à faire, c'est d'enregistrer les notifications sur toutes les fenêtres ouvertes du Finder (et sur le bureau), et d'attendre tout simplement que l'OS l'informe de tout évènement intéressant. Problème résolu, et d'une façon qui place l'utilisateur au premier rang.

Malheureusement, le Finder de Panther ne fait pas cela. Cette caractéristique n'est pas absente à cause de la difficulté de son implémentation. Après quelques jours d'efforts, une poignée de lecteurs de Ars Technica a été capable d' élaborer quelque chose qui fait le travail. Vous pouvez en trouver le code source, et quelques instructions pour la compilation dans ce fil de forum. Le code ne fait que deux pages de long, et la partie la plus difficile est de trouver un moyen d'interroger le Finder sur les fenêtres qui sont ouvertes. Le code doit (malheureusement) interroger le Finder périodiquement pour obtenir cette information. Les développeurs du Finder d'Apple ne devraient pas avoir ce problème.

Alors, pourquoi n'y a-t-il (apparemment) aucun support de kqueue dans le Finder de Panther ? Je suppose qu'Apple envisage de rajouter un nouvel outil de notification de haut niveau (ou d'en ré-implémenter un qui existe) au dessus de kqueue, avec les APIs de Core Foundation, et de positionner Carbon et Cocoa au dessus. C'est un plus gros travail de conserver la structure des APIs de Mac OS X que de demander à l'équipe du Finder d'utiliser directement les API de kqueue (qui sont de l'Unix). Mais je peux me tromper, et ce pourrait être le manque de temps qui a maintenu kqueue à l'écart du Finder. Quoi qu'il en soit, dans Mac OS X 10.4, l'équipe du Finder devrait afficher "kqueue ou l'éclatement".