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 (5)







Les performances

Panther est plus rapide que Jaguar. Il y a plusieurs façons de voir les choses. D'abord, l'ennuyeuse performance numérique classique. Vous savez, les benchmarks et tout le tintouin. Panther l'emporte principalement en technicité : gcc3 produit un code plus optimisé, et peut mieux tirer parti du G5. Panther est lui même construit avec gcc3, et nous y voilà.

Mais la "performance ressentie" est là où Mac OS X a toujours souffert. En ce qui concerne le ressenti de l'utilisateur, si cela semble lent, c'est lent. Panther s'est aussi amélioré dans ce domaine. J'ai du mal à trouver un élément de l'interface utilisateur qui ne semble pas notablement plus rapide sous Panther que sous Jaguar. C'est comme si l'OS avait été débarrassé de ses toiles d'araignées. Il y a beaucoup moins d'attentes ennuyeuses dans l'IU. Les animations ont moins de vues, et se déroulent plus rapidement. Et oui, même les fenêtres se re-dimensionnent plus rapidement.

C'est principalement le résultat d'une optimisation d'un ensemble d'opérations courantes. Notamment, tout ce qui concerne le texte (mesure du texte, positionnement du texte, écriture du texte, etc...) a été nettement amélioré sous Panther. Cela semble une optimisation plutôt laborieuse, mais cela paie vraiment.

Voici maintenant une autre façon de considérer les performances de Panther. Depuis trois ans maintenant, Mac OS X est devenu plus rapide à chaque nouvelle version, pas simplement "plus rapide selon l'expérience de la plupart des utilisateurs finaux", mais aussi plus rapide sur un même matériel. Cette tendance est inconnue sur la plupart des OS de bureau contemporains. Ce n'était à coup sûr pas le cas de Mac OS classique, où chaque nouvelle version significative du système était plus lente que la précédente sur un même matériel. (Oui, System 7 et System 8, vous êtes visés). Le monde de Windows suit une tendance similaire. On admet généralement qu'un nouvel OS ne va pas vraiment briller, à moins que vous ne mettiez à jour votre matériel.

Ce n'est pas le cas de Mac OS X, et mon G3/400 bleu et blanc l'atteste. Il a abrité toutes les nouvelles versions de Mac OS X qui sont sorties, et ce foutu machin devient de plus en plus rapide.

Bien sûr, vue sous un angle plus pessimiste, la performance de Mac OS X ne pouvait qu'augmenter ! Et comme System 7 et Mac OS 8 auparavant, Mac OS X est en fait sensiblement plus lent sur un même matériel que son lointain prédécesseur Mac OS 9. Mais je peux confirmer que les transitions entre 10.1-10.2 et 10.2-10.3 sont au moins aussi significatives, mesurées en termes de modifications de lignes de code et de nouvelles caractéristiques, que le passage de Système 6 à Système 7 ou de Système 7 à Mac OS 8. Je pense qu'il est légitime de reconnaître l'amélioration de Mac OS X quand elle intervient.

Les raisons partielles de la lente évolution de Mac OS et des baisses de performances tiennent dans la nature du code. Mac OS classique est un paquet confus de bouts de ficelle comparé à l'agencement soigneusement ordonné des composants de Mac OS X. Mac OS X change de façon aussi efficacement, et s'améliore aussi rapidement parce qu'il le peut. Des sous-systèmes complets sont réécrits, re-codés et re-synchronisés, le travail étant fait ailleurs (entendez FreeBSD, XFree86, OpenSSL, etc...) à un point qui ferait (et le fait sans doute) tourner la tête d'un programmeur de Mac OS.

Pour ceux qui n'y ont pas pris garde, c'est le grand intérêt d'avoir choisi la plateforme NeXT basée sur Unix comme base au nouveau système d'Apple depuis toutes ces années. Cela a fourni à Apple une fondation modulaire reposant sur Unix, qui est bien comprise par des légions de développeurs doués, qu'Apple a rapidement (et habilement) récupérés et mis au travail sur Mac OS X.

A chaque WWDC, je suis de plus en plus impressionné par le simple volume de "choses" qui ont été modifiées sous le capot de Mac OS X à chaque nouvelle version. Apparemment, tout est bon à prendre. L'inconvénient potentiel, c'est que les développeurs de Mac OS X doivent être réactifs pour tenir le rythme des développeurs de l'OS d'Apple. Alors qu'Apple excelle à conserver les APIs existantes, les nouvelles APIs sont si attirantes que tout développeur qui les néglige se trouve désavantagé vis à vis de la concurrence. Il apparaît que seuls les forts peuvent survivre.


La gestion des fenêtres

Et maintenant, prenons un peu de champ. Si Panther est effectivement plus rapide que Jaguar sur un même matériel, il n'est pas encore assez rapide dans de nombreux domaines. Ces damnées toiles d'araignée n'ont pas encore été complètement éliminées de Panther. La manipulation des fenêtres, en particulier, s'interrompe encore parfois, bégaye, et généralement reste en retard sur mon état mental.

Et cela inclut bien sûr notre vieux ressentiment, le redimensionnement des fenêtres. Alors que la vitesse de redimensionnement est acceptable sur un G5 musclé, j'en suis à me demander ce qui la ralentit (encore) un peu. Est-ce le CPU quand il dessine par logiciel le contenu de la fenêtre plutôt que d'utiliser la carte vidéo ? Est-ce que la bande passante de la mémoire est encore un problème sur un Mac avec un bus à 1 G Hz ? Le responsable est-il en fait une surcharge de l' IPC associée au serveur de fenêtre ? Je suis à court d'idées. Il semble certain que ce "problème" va finalement se résoudre de lui-même à mesure que les Macs deviendront (enfin) plus rapides, mais nous n'en sommes pas encore là.

Clutter (1), une application qui crée une petite fenêtre pour chaque album de votre collection de musique iTunes fournit un bon test pour la gestion des fenêtres.

figure

Clutter : environ 130 fenêtres (quelques unes superposées)

Le simple fait de montrer et de cacher l'application Clutter (et toutes ses fenêtres) prend environ 1,5 seconde sur un G5 dual à 2 GHz, avec 1,5 Go de RAM et 128 Mo de VRAM. Vous pouvez réellement observer l'apparition ou la disparition de clutter, un album à la fois. Moins de deux secondes ne paraît pas très long, mais vous serez surpris de constater que cela paraît long quand vous "attendez votre ordinateur", notamment quand il s'agit de passer d'une application à une autre, en cachant ou en montrant des fenêtres au fur et à mesure. Le basculement de visibilité des fenêtres devrait être instantané, et je voudrais savoir exactement ce qui provoque ce retard.

Les performances du disque

C'est un mauvais coup de la vie que la plupart des opérations qui ralentissent l'utilisation quotidienne d'un G5 dual soient associées aux entrées/sorties. La performance du disque est ce qui empêche les applications de se lancer immédiatement, ou les dossiers et les fichiers d'être copiés sans l'affichage de barres de progression ennuyeuses. Et quand le système de mémoire virtuelle commence à dérailler, chaque opération devient soudain conditionnée par la vitesse du disque.

Historiquement, Mac OS X a géré ce problème de plusieurs façons. La solution la plus facile est simplement de faire moins d'entrées/sorties sur le disque. Les performance de lancement des applications ont été largement améliorées dans les premières versions d'OS X en réduisant le nombre de frameworks lus sur le disque pendant le processus de lancement. La seconde solution est le cache. Mac OS X a toujours entrepris d'utiliser chaque élément de RAM disponible comme cache de fichier. Panther va un peu plus loin, avec deux nouvelles caractéristiques : le défragmentation automatique des fichiers, et le regroupement des fichiers critiques.

Un fichier se trouve fragmenté quand les données qu'il contient se trouvent dispersées partout sur le disque au lieu d'être situées dans un seul ensemble contigu de blocs du disque. Comme le déplacement de la tête de lecture d'un endroit à un autre du disque est une des opérations les plus lentes possible, les fichiers fragmentés ont un temps de lecture disporportionné. Il est difficile d'éviter entièrement la fragmentation, notamment pour des fichiers qui s'accroissent lentement, ou sans limites. La défragmentation récupère les données d'un fichier fragmenté, et les déplace dans un espace libre contigu du disque (en supposant qu'il y en ait un assez grand).

Dans certaines circonstances, Panther défragmente les fichiers automatiquement. Vous pouvez lire le fil de Macintoshian Achaia pour les détails sanglants, mais la réponse courte est que les fichiers inférieurs à 20 Mo sur un disque HFS+ journalisé sont défragmentés automatiquement sous Panther à chaque fois qu'ils sont ouverts en lecture ou en écriture.

Cela m'interpelle comme une forme d'optimisation mal pensée. D'abord, cela semble stupide qu'on puisse écrire sur le disque jusqu'à 20 Mo de données lors d'une simple opération d'ouverture du fichier (notez qu'il n'y a pas de lecture ou d'écriture de données, simplement l'ouverture du fichier). Ensuite, si la défragmentation est un tel problème sur les disques HFS+ journalisés, une meilleure solution serait d'améliorer la gestion de l'allocation, ou encore mieux, de remplacer HFS+ par un meilleur système de fichiers (ce que fait Apple en tout état de cause avec son projet d'amélioration des méta-données du système. Pas vrai ?)

Quoi qu'il en soit, je suis tout disposé à accorder aux développeurs HFS+ d'Apple le bénéfice du doute, et à admettre que cette optimisation est le résultat d'une amélioration de performance, et a été testée et appliquée pour fournir une amélioration de performance effective lors d'un usage typique.

Le regroupent de fichiers critiques (hotfile clustering), aussi détaillé dans le forum, est une autre optimisation que j'ai instinctivement considérée comme prématurée. Panther guette les fichiers utilisés fréquemment, et les déplace vers un espace plus rapide du disque. Cela n'intervient que pour le disque de démarrage, et il y a des contraintes sur le nombre et la taille des fichiers éligibles. Un effet secondaire est que le déplacement des fichiers vers des espaces d'accès rapide provoque aussi leur défragmentation.

Il me semble que cette optimisation essaie de dépasser le mécanisme normal de cache des fichiers. Mais comme pour la défragmentation automatique, je voudrais être assuré par des tests que cette modification se justifie. Je peux concevoir qu'elle fonctionne réellement bien avec un cache normal de disque, puisqu'on peut supposer que tout fichier utilisé fréquemment sera dans une espace contigu du cache dans la zone d'accès rapide (disons, trois fois plus rapide).

La preuve est dans les faits : Panther déraille moins que Jaguar sur un même matériel, selon mon expérience. Mais cela peut être attribué à beaucoup de choses, et le fait qu'il s'agisse d'un OS fraîchement installé n'est pas la moindre. Mais souvenez vous que j'ai fait une installation "normale" de mise à jour, plutôt qu'une installation nouvelle, et je voudrais pouvoir considérer que ces deux nouvelles caractéristiques sont au moins en partie responsables de la diminution d'activité du disque.

Voici une dernière anecdote sur la performance du cache de fichier sous Panther. Il me fallait récupérer quelques icônes pour cet article, à partir des CDs d'installation de Jaguar, parce que j'avais oublié de les sauvegarder avant la mise à jour. Elles étaient stockées dans une grosse (plus de 100 Mo) archive compressée sur le CD. J'ai utilisé le programme en ligne de commande pax pour décompresser l'archive à la volée et extraire les fichiers. Après avoir récupéré la première, icône, je me suis aperçu que le CD avait cessé de tourner dans le lecteur (c'est très audible sur un G5). J'ai alors entrepris de récupérer le reste des fichiers à partir de la même archive et le CD ne s'est jamais remis en route. Voilà une forme de cache du disque agréable.

Conclusion sur les performances

Il est difficile de critiquer une mise à jour d'OS qui rend l'ordinateur plus rapide. Sur chacun de mon G3/400 bas de gamme et de mon puissant G5 (qui a commencé son existence avec Jaguar), la mise à jour vers Panther a fourni une amélioration de performance immédiate et notable. Que dire de plus ? Les performances de Panther correspondent à son nom impressionnant.


(1) Note du traducteur : les liens vers les pages qui n'existent plus n'ont pas été reportés. Voyez le texte original si vous voulez les connaître, mais cela ne vous servira pas à grand chose...