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

Mac OS X 10.1




7- L'utilisation de la mémoire.

Si vous lisez cet article pour des tuyaux sur la manière d'améliorer votre expérience avec Mac OS X, c'est maintenant le moment de faire attention. En dehors de l'achat d'un nouveau mac, la chose la plus importante que vous pouvez faire pour rendre Mac OS X plus supportable est d'acheter plus de RAM. Allez-y, n'ayez pas honte. Les barrettes de 512 Mo se trouvent à 50 $ si vous cherchez un peu.

Les lecteurs réguliers se rappellent que le G3/400 et le G4/450 avaient tous deux 256 Mo de RAM au moment du rapport sur 10.0. Après avoir utilisé 10.0.x pendant quelques semaines sur le G4, j'en ai eu assez d'entendre mon disque mouliner en permanence, et je l'ai mis à jour à 512 Mo. Le silence qui s'en est suivi était d'or. C'est la plus grosse amélioration parmi toutes les mises à jour de 10.0.x, de loin.

(Bien que le G3/400 fonctionnait principalement sur Mac OS 9, je l'ai mis à jour à 384 Mo parce que, eh bien, la RAM était assez bon marché pour ne pas s'en priver, je suppose).

Après quelques semaines à 512 Mo, Le G4 a recommencé à mouliner un peu. J'ai échangé un peu de RAM entre mes machines pour booster à nouveau le G4, avec un total actuel à 768 Mo, et j'ai remarqué une amélioration à peu près linéaire de fonctionnement dans l'utilisation journalière.

Que se passe-t-il ? Où va toute cette mémoire ? Mac OS X serait-il un trou noir pour la RAM ? Dans un sens, oui. Mais c'est en réalité une bonne chose, enfin presque. J'ai parlé du système de mémoire virtuelle de Mac OS X en relation avec l'expérience de l'utilisateur, et de l'infamant "système minimum requis" dans l' article sur 10.0. Je voudrais m'écarter un peu de l'aspect "rapport" de cet article, pour aller plus en détail sur le système de mémoire de Mac OS X (comme l'ont demandé de nombreux lecteurs). Autorisez-vous à sauter à la conclusion si vous êtes seulement intéressé(e) par la performance d'utilisation de la RAM de 10.1 relativement à 10.0.x.

(Note : une grande partie de l'information présentée ci-dessous est largement simplifiée dans un effort pour atteindre une audience aussi large que possible. Si vous êtes intéressé(e) par les détails sanglants, l'utilisation d'un bon bouquin sur le sujet sera votre meilleure action).

Les bases de la mémoire virtuelle

Mac OS X gère la mémoire d'une façon très différente de Mac OS classique. La première règle pour comprendre l'utilisation de la mémoire sous Mac OS X est de comprendre comment un système de mémoire virtuelle moderne fonctionne.

Dans un système de gestion de mémoire virtuelle, on fait la distinction entre la mémoire physique, réelle, et la mémoire "virtuelle". La taille de mémoire virtuelle d'une application est la quantité de mémoire que l'application "pense" avoir allouée, mais seule une portion (qui peut être très petite) de cette mémoire peut effectivement être stockée dans les chips de la RAM physique (réelle) qui sont installés à un moment donné sur la carte-mère de votre ordinateur. le reste est stocké sur le disque, sous une certaine forme, en général dans un ou plusieurs fichiers de swap (d'échange).

Le système d'exploitation décide quelle portion de certains processus occupe la mémoire physique à tout moment. Le processus de décision est compliqué et varie d'un OS à un autre, mais il utilise en général des statistiques récentes pour prendre la décision. Un processus qui n'a pas accédé à une portion de la mémoire réelle (physique) depuis un certain temps peut voir cette mémoire écrite sur le disque, pour qu'un autre processus actif puisse utiliser ce morceau de mémoire physique. Quand un processus a une large portion de sa mémoire écartée de la RAM physique, et placée sur le disque, on dit qu'il est "swapped out" (échangé).

Si un processus doit utiliser à nouveau une portion de mémoire échangée, celle-ci sera transférée du disque vers la mémoire physique, possiblement à un autre endroit que celui qu'il occupait précédemment. Quand une application précédemment échangée redevient active, et qu'une large portion de sa mémoire est déplacée du disque vers la mémoire physique, on dit qu'elle est "swapped in" (réintégrée).

Pour simplifier la gestion de la mémoire, le système d'exploitation procède avec des unités uniformes d'une taille minimum (en général 4 Ko) appelées "pages". Echanger une page est aussi appelé "pageout", et réintégrer une page s'appelle "pagein". L'organisation utilisée pas le système d'exploitation pour contrôler la gestion de la mémoire est souvent appelée "l'algorithme de pagination".

Les pages de mémoire peuvent stocker presque n'importe quoi ; du code, des données, et même des morceaux de fichiers. En fait, l'un des avantages de la mémoire virtuelle, c'est que des fichiers entiers peuvent être mis en mémoire ("memory mapped") : on peut accéder à un fichier sur le disque comme si c'était un ensemble de pages de la mémoire qui ont été échangées sur le disque.

Une optimisation supplémentaire est possible en permettant à des processus qui ont besoin de la même information (du code, des données, des fichiers), de partager des pages de mémoire. Quand un processus qui partage une page de mémoire particulière choisit de modifier cette page, une copie privée est créée. Ce comportement est appelé "Copy-on-write", et permet à beaucoup de processus de se partager efficacement la mémoire, en allouant séparément les différences.

La totalité de la mémoire ne peut pas être échangée. Certaines pages sont "câblées" (wired-down), ce qui veut dire qu'elles ne peuvent jamais quitter la mémoire physique de toute leur existence. Les pages de mémoire qui contiennent le code du système d'exploitation qui contrôle l'algorithme de pagination ne peuvent jamais être échangées par exemple (il suffit d'y réfléchir). En fait, la plus grande partie du noyau du système d'exploitation est normalement câblée.

Chaque processus actif a besoin qu'une portion minimum de ses pages de mémoire réside en mémoire physique pour fonctionner avec efficacité. Cette portion est appelée l'"ensemble de travail" (working-set). Quand l'ensemble de travail de tous les processus actifs ne peut pas résider dans la mémoire physique, le système d'exploitation doit en permanence échanger des pages entre la mémoire physique et le disque, dans une sorte de jeu de chaises musicales qui devient terriblement mauvais. On dit d'un ordinateur qui est dans cet état qu'il s'est emballé ( thrashing). La seule solution est de réduire le nombre de processus actifs, ou d'acheter plus de RAM.

Le tampon de cache.

Le second facteur le plus important du comportement de la mémoire sous Mac OS X est le tampon de cache. Ce tampon sert à accélérer l'accès aux fichiers sur le disque. A chaque fois qu'un morceau de données est lu sur le disque, il peut être (sur option) stocké en mémoire. Si on a besoin de ce même morceau de données dans un futur proche, il peut être encore disponible dans la mémoire physique, ce qui évite une lecture sur le disque. Mac OS X comprend un "tampon de cache unifié", ce qui veut dire que le tampon de cache et la mémoire virtuelle sont combinés. Une page est une page, toujours une page, sous OS X.

Le tampon de cache affecte l'utilisation de la RAM de façon inattendue pour l'utilisateur. Les entrées/sorties massives de fichiers peuvent utiliser une grande quantité de mémoire physique très rapidement, et réduisent potentiellement la présence de mémoire pour les applications. Des applications mal écrites peuvent exacerber ce problème en utilisant des entrées/sorties de fichiers en cache quand ce n'est pas nécessaire, ni même utile. Un application qui lit et examine un énorme fichier une seule fois au démarrage ne doit pas utiliser le cache d'entrée/sortie puisqu'elle n'est pas susceptible d'utiliser ces pages à nouveau par la suite, avant qu'elles n'aient été évincées de la mémoire physique par un autre processus actif.

Le serveur de fenêtre

Le dernier acteur majeur dans le ballet de mémoire de Mac OS X est , d'une façon surprenante, le serveur de fenêtres. Celui-ci orchestre l'accès à l'écran, et comprend à la fois les dessins de base et des concepts de haut niveau comme les mouvements et la superposition des fenêtres.

Comme je l'ai abordé dans des articles précédents, la couche d'affichage de Quartz (dont le serveur de fenêtres est un élément important) modèle l'écran à la manière d'un moteur de composition en couches, comme les couches dans une application graphique telle que Photoshop. Chaque pixel a des composantes rouge, vert, bleu, plus un "canal alpha" qui détermine sa transparence, depuis l'opacité totale jusqu'à l'invisibilité complète. L'apparence de chaque pixel sur l'écran est déterminée par la composition de toutes les applications qui contrôlent un pixel à cette position. Le serveur de fenêtres calcule la composition de tous ces pixels sur la base de la superposition des couches et de la visibilité des pixels qui y participent.

Cela fournit une infrastructure pour beaucoup des effets attractifs de Mac OS X : l'ombre portée transparente des fenêtres, les menus et les barres de titre semi transparents, etc. Chaque application particulière n'a besoin de se préoccuper que de ses propres pixels, sans considération de ce qui peut être devant ou derrière. Le serveur de fenêtres fait la composition de tous ces pixels et dessine le résultat sur l'écran. Cela rend le développement des applications plus simple, en laissant le "travail difficile" de création de ces effets au système d'exploitation, plutôt qu'à l'application.

Les choses deviennent à nouveau compliquées quand quelque chose sur l'écran doit se déplacer, ou changer de couleur (ou de transparence). Le serveur de fenêtres doit recomposer chaque pixel modifié par l'application avant que la modification ne devienne visible pour l'utilisateur. Et les calculs de composition ne nécessitent pas seulement la valeur du pixel modifié, mais aussi les valeurs de tous les autres pixels qui participent à cette position.

Imaginez les calculs nécessaires pour faire quelque chose d'aussi simple que le déplacement d'une fenêtre sous Mac OS X. Chaque pixel de cette fenêtre doit être recomposé avec tous les pixels de toutes les applications à chaque endroit pour la nouvelle position de la fenêtre. Représentez-vous une fenêtre de 500 x 300 pixels (environ 24 lignes de 80 colonnes de texte) déplacée vers la droite de 100 pixels, avec 5 autres applications derrière elle. Cela fait environ 15 millions de calculs de composition, chacun avec 30 opérandes (valeurs rouge, vert bleu et alpha, pour chaque pixel concerné pour chaque application), tout ça pour déplacer une petite fenêtre de quelques centimètres.

Mais attendez, ce n'est pas tout. Quand quelque chose change sur l'écran (une fenêtre qui se déplace, apparaît ou disparaît), les pixels qui appartiennent aux autres applications sont révélés. Ces pixels doivent évidemment être composés avant d'être affichés, et ces calculs de composition ont besoin de toutes les valeurs de pixels pour chaque application qui a un pixel dans la nouvelle zone révélée. L'ajout de ces calculs de composition à la zone nouvellement révélée dans l'exemple de la fenêtre déplacée ci-dessus (en prenant en compte l'ombre portée transparente sur la fenêtre) porte le total de calculs à 17 millions avec 20 à 30 opérandes !

Bien sûr, c'est le scénario le pire, qui n'arrivera que lors d'une implémentation très naïve. Beaucoup d'optimisations sont possibles. Les pixels opaques peuvent abréger le nombre et la difficulté des calculs de composition de façon considérable, particulièrement quand le pixel le plus en avant est opaque.

Mais on ne peut pas contourner le fait que le serveur de fenêtres a toujours besoin de l'accès à tous les pixels de toutes les fenêtres de l'écran à tout moment, du fait qu'il ne sait jamais quand l'un d'entre eux aura besoin d'un calcul de composition. En plus cet accès doit être très rapide, car il n'est pas question d'attendre que l'OS lise les pixels sur un médium aussi lent qu'un disque.

Mac OS X fournit un serveur de fenêtres avec un accès rapide aux pixels en mettant toutes les fenêtres en tampon. Tous les pixels d'une fenêtre en tampon sont stockés en mémoire. Quand on a besoin d'un de ces pixels pour un calcul de composition, le serveur de fenêtre se contente de lire la position de mémoire correspondant à ce pixel. Il n'a pas à interroger l'application pour ce pixel. En fait, l'application peut être entièrement gelée, et sans réponse, mais sa fenêtre peut encore être déplacée, cachée ou rafraîchie sans que l'application y participe. Quand une application veut modifier sa fenêtre, les modifications sont envoyées au serveur de fenêtres, qui met à jour le tampon de la fenêtre pour refléter les changements.

Cela représente un grand changement par rapport à Mac OS classique , où chaque application dessinait directement sur l'écran, et où toute nouvelle portion de fenêtre avait à être réécrite par l'application qui possédait la fenêtre. Les tampons de fenêtre et la composition devaient être réalisés implicitement par toute application qui le voulait, et c'était complètement indépendant de toutes les autres applications en fonctionnement.

Du point de vue du développement, les fenêtres en tampon rendent les applications plus faciles à coder. Le tracé ne doit être fait qu'une fois, après quoi des portions de fenêtre peuvent être cachées ou révélées sans entraîner de code de tracé nouveau de la part de l'application. Dans la perspective de l'utilisateur, le tamponnage des fenêtres permet la révélation de fenêtres qui se trouvent être là, sans nouveau tracé visible. Le tamponnage permet aussi un mouvement progressif et sans à coups des fenêtres. Mac OS X va même assez loin pour synchroniser le tracé sur l'écran avec le balayage des électrons sur le tube cathodique, pour éviter les scintillements et les parasites.

Le tamponnage sous Quartz est dans l'ensemble une bonne chose. Il améliore la qualité visuelle des éléments sur l'écran, et rend le développement des applications plus facile. Mais, qu'est-ce que tout cela a à voir avec l'utilisation de la mémoire ?

On a déjà vu le nombre potentiellement énorme des calculs nécessaires à la composition d'items sur l'écran. Ces calculs sont tous faits par le CPU sous Mac OS X, et ne sont pas dévolus au GPU de la carte vidéo. Mais ce qui est surprenant, c'est que ce n'est pas un accès aussi important au CPU qu'on pourrait s'y attendre, du fait du cas normal des pixels opaques, et de la vitesse des CPUs d'aujourd'hui (oui, même sur les Macs). Quelques millions de calculs de temps en temps peuvent entraîner une charge supplémentaire sur le CPU, mais ce n'est pas vraiment un problème sur le long terme. Cela dit, ce serait bien d'avoir une carte vidéo pour faire ces calculs, plutôt que le CPU, quelque chose sur lequel je suis sûr qu'Apple travaille. Dans les cas les plus graves, (par exemple la fenêtre transparente du terminal), la charge du CPU peut momentanément devenir déterminante.

Mais c'est l'utilisation de la mémoire qui est le principal problème. Les applications de Mac OS classique n'ont besoin de retenir que l'information essentielle pour chaque fenêtre : sa taille, ses caractéristiques, son contenu. Les applications Mac OS X doivent bien sûr retenir la même information, mais se rappeler que le serveur de fenêtres doit retenir une image complète de chaque pixel dans la fenêtre. Répétez cela pour chaque fenêtre de l'écran, et cela se cumule très rapidement.

Mac OS classique ne réclame que quelques kilo-bytes pour stocker les structures de base qui définissent une fenêtre simple et vide. Sous Mac OS X, la mémoire totale nécessaire même pour une fenêtre entièrement vide, est proportionnelle à sa taille, quelle que soit la nature de son contenu (si elle en a un).

Dans mon travail quotidien en tant que programmeur web, cette différence est visible. La nature du travail suppose que plusieurs fenêtres soient ouvertes en même temps : des éditeurs de texte, des navigateurs, des terminaux. Sous Mac OS classique, chaque fenêtre d'éditeur de texte , par exemple, ne requiert que la petite quantité de mémoire pour la fenêtre elle-même, plus tout ce que l'éditeur conserve comme texte (en ASCII) dans chaque fenêtre. Sous Mac OS X, chaque fenêtre d'un éditeur de texte devient une énorme image sur 32 bits (avec en plus, bien sûr, le reste de l'information). Multipliez cela par le nombre des applications utilisées, chacune avec ses propres fenêtres, et vous arrivez rapidement à des problèmes.

Voyez cette liste des fenêtres pour un jour typique de travail sur mon G4. La mémoire totale utilisée par les tampons de fenêtre seuls atteint une valeur impressionnante de 120 Mo ! Et rappelez vous que c'est avant même de prendre en compte des choses comme, disons, la mémoire nécessitée par les applications, et le cœur de l'OS lui-même.

(La possibilité de réduire l'utilisation de mémoire du serveur de fenêtres et -de façon plus importante, de réduire la bande passante de l'utilisation de la mémoire-, en compressant les tampons de mémoire inactifs est fascinante,mais cela n'est pas officiellement supporté sous Mac OS X 10.1).

Le serveur de fenêtres utilise bien sûr le même système de mémoire virtuelle que n'importe quelle autre partie de Mac OS X . Cela signifie que la mémoire qui constitue chaque tampon de fenêtre est susceptible d'être paginée comme n'importe quel autre morceau de mémoire. C'est là qu'intervient le vrai problème de performance. Une tentative de manipuler une fenêtre dont une partie ou la totalité du tampon a été échangé est une expérience douloureuse, bégayante, de moulinage du disque, à mesure que le système de mémoire virtuelle cherche à récupérer ces pages dans la mémoire physique (en éliminant, bien sûr, d'autres pages résidentes pour cela).

Je rencontre ce phénomène sur une grande échelle à chaque fois que je reviens au travail le lundi, après un week-end passé à me connecter au G4 à l'aide de la ligne de commande en appelant des applications sans IUG à partir du terminal. Ces lundi matins, presque n'importe quel tampon de fenêtre est susceptible d'avoir été échangé pendant le week-end. La session de moulinage du disque qui s'assure que toutes les fenêtres sont réintégrées quand je commence à les utiliser est tout à fait spectaculaire.

Et rappelez-vous que c'est un système avec 768 Mo de RAM. Mais l'OS s'en soucie peu. Mon travail en ligne de commande du week-end réclame beaucoup de mémoire (compilation, appel à des serveurs web), et l'OS la fournit. Aucune des applications GUI n'est active pendant le week-end, si bien que leurs pages ont été échangées vers le disque pour faire de la place aux besoins en mémoire de l'activité en ligne de commande. Cela doit être considéré comme une caractéristique.

Alors, les fenêtres tamponnées : amis ou ennemis ? En définitive, ce sont des amis. Le serveur de fenêtres d'OS X fournit un haut niveau d'abstraction pour les applications. Une abstraction supérieure entraine plus d'utilisation de ressources. mais une "abstraction accrue" représente la définition du progrès dans l'industrie informatique (autrement, on en serait encore à programmer en langage machine). Mais, comme beaucoup du reste de l'OS, un tamponnage envahissant des fenêtres est un peu en avance sur l'état actuel du matériel. Sur le long terme, c'est aussi une bonne chose, à mon avis. Il est plus facile d'attendre que le matériel s'adapte à votre ambitieuse, (mais propre) une architecture logicielle que d'essayer de remodeler le système d'exploitation en réponse aux progrès du matériel (demandez à Apple;-).

Optimisation des fichiers d'échange

Comme il est possible d'utiliser presque n'importe quelle quantité de mémoire physique sous OSX (j'ai rempli mes 768 Mo très vite), d'autres gains de performance sont encore possibles en déplaçant les fichiers d'échange vers un disque séparé. Quelle que soit la quantité de RAM que vous ayez, vous utiliserez presque certainement des fichiers d'échange un jour. Les têtes du disque contenant l'OS et les applications seront déjà occupées à lire et écrire les fichiers de code et de données de l'OS et des applications. Leur rajouter un arrêt sur un fichier d'échange pendant leur voyage erratique ne fait que rajouter à la cacophonie du moulinage du disque. L'accès aux fichiers d'échange est particulièrement pénible, puisqu'il s'intercale au milieu des autres opérations de disque. : Lire un morceau de fichier de données dans un tampon de cache, écrire une vieille page de mémoire sur un fichier d'échange, lire un morceau de code d'application depuis le disque vers la mémoire, etc, etc... (Vous entendez mouliner ?)

Positionner les fichiers d'échange sur un disque séparé permet aux têtes du disque de bénéficier d'une meilleure référence de localisation (c'est à dire qu'elles n'ont pas à se déplacer autant), et libère le disque des applications et de l'OS qui peut se consacrer à ses tâches. Il n'y a aucun moyen reconnu par Apple pour déplacer les fichiers d'échange sur un autre disque, et pas d'utilitaire GUI pour cela. Mais les utilisateurs courageux peuvent suivre des conseils disponibles sur le web. Assurez-vous seulement de faire une copie complète d'abord, parce que vous pouvez paralyser complètement votre OS si vous ne faites pas attention.

Je n'ai qu'un seul disque au travail, mais à la maison, j'ai déplacé mon fichier d'échange du disque 12 Go/5400 TMP qui héberge l'OS et toutes les applications vers mon disque de 45 Go/7200 TPM de Mac OS 9. Le moulinage du disque s'est réduit substantiellement.

Le simple déplacement du fichier d'échange sur une partition spécifique sur le même disque est d'un bénéfice beaucoup moindre (s'il y a bénéfice). Les têtes du disque ont toujours besoin d'effectuer des allers et retours entre la partition d'échange et le reste du disque. Et comme Mac OS X utilise des fichiers d"échange séparés (plutôt qu'un système dédié de fichier d'échange), une partition d'échange séparée est seulement susceptible de faire la différence de façon significative si les fichiers d'échange sont fortement fragmentés sur le disque. (Notez que je parle de fragmentation externe, où des morceaux de chaque fichier d'échange sont répartis partout sur le disque. Les fichiers d'échange eux-mêmes sont toujours intensément fragmentés de façon "interne", ce qui signifie que des morceaux différents de mémoire sont disséminés à l'intérieur de chaque fichier d'échange).