Caractéristiques d'un "grand" logiciel (1)
La performance, c'est la perception par l'utilisateur de la vitesse de réaction et de l'efficacité du logiciel, et elle en conditionne le succès. Si le logiciel paraît lent, les utilisateurs ne sont pas enclins à l'acheter. Un logiciels dont les algorithmes sont optimisés peut paraître lent s'il met trop de temps à répondre à l'utilisateur.
Les développeurs sont donc invités à tenir compte des facteurs qui influencent la performance, dans la conception et l'implantation de leur programme :
• Identifier les problèmes de performance à l'aide de mesures, pas de suppositions ; utiliser les outils fournis par Apple, comme Shark, et utiliser les données receuillies pour identifier les problèmes et les résoudre. Il est possible de mettre en place son propre ensemble de mesures.
• Se préoccuper des performances dès le début du cycle de développement, et se fixer des objectifs. Comparer les mesures pendant le développement, et si la performance se dégrade, prendre immédiatement les mesures de correction nécessaires.
• Utiliser les APIs les plus récentes, qui fournissent les meilleurs solutions et tirent avantage des dernières technologies
• Choisir les technologies appropriée à la tâche entreprise : les objets distribués Cocoa sont plus faciles à utiliser, mais pour une meilleure performance du réseau, leur préférer le framework CFNetwork et les sockets BSD.
• Utiliser des threads pour améliorer l'exécution du code ; les threads permettent le parallèlisme sur les systèmes mutli-processurs, et fournissent des gains de performance appréciables.
• Eviter l'interrogation régulière des périphériques (polling) ; les APIs récentes fournissent des fonctions de rappel (callback) pour notifier des modifications de conditions de façon asynchrone, et évitent au CPU de perdre son temps.
• Supprimer les opérations d'entrées/sorties inutiles, notamment sur les disques magnétiques ou optiques. Réduire ces opérations procure des gains de performances considérables.
• Utiliser au mieux le système de mémoire virtuelle de Mac OS X.
• Ne charger les ressources que quand on en a besoin, et les conserver alors en mémoire cache.
• Utiliser le format d'exécutable Mach-O, qui est utilisé par tous les frameworks du système. Délaisser le format CFM (Code Fragment Manager) qui est dépassé.
Pour un développeur, respecter ces consignes n'est pas une sinécure : au delà du code de sa propre application, cela l'entraîne nécessairement sur des chemins de traverse (pour en avoir une idée, suivez les liens de la page d'Apple), et l'oblige à connaître un grand nombre d'APIs et de frameworks. C'est une tâche extrêmement difficile, qui est bien dominée par les ingénieurs d'Apple, mais, avec les modifications incessantes des APIs, rend le travail du développeur compliqué et périlleux.
La roulette de la mort.
Sur mon MacPro 8 cœurs avec 12 Go de mémoire vive, je ne ressens pas trop ces problèmes de performance en utilisant les applications, sauf pendant le démarrage, et lors des interventions intempestives et fréquentes de la roulette multicolore qui s'invite à la fête pour des temps parfois très longs (10 à 15 secondes). John Siracusa explique l'irruption de la roulette multicolore par un cœur saturé par le thread principal. Cela se produit le plus souvent lors des accès au système de fichiers, et démontre que HFS+ n'est plus à la hauteur des besoins actuels. Même Apple est incapable de résoudre ces problèmes, tant qu'elle n'aura pas enfin mis en place un nouveau système de fichiers, plus robuste et mieux conçu ; l'abandon de ZFS par Apple a peut-être de bonnes raisons, mais il ne fait que retarder la solution à un problème de performance inadmissible sur un système comme Mac OS X.
Les applications d'Apple ne sont pas non plus exemptes de problèmes de performance ; le cas le plus typique est iPhoto. Les 89 photos qui résident actuellement sur ma bibliothèque iPhoto utilisent environ 180 Mo. Ces mêmes photos rangées dans le système de fichiers occupent autour de 120 Mo. Un défaut de performance de l'ordre de 30 %, qui s'explique par le système de fichiers aberrant utilisé par iPhoto (pour en avoir un aperçu, faites un Ctrl-Clic sur votre bibliothèque iPhoto, et choisissez "Afficher le contenu du paquet" dans le menu contextuel). 89 photos, ce n'est pas la lune ; imaginez la place mémoire gâchée si vous en avez des milliers ! C'est pourquoi, en ce qui me concerne, je ne conserve pas mes photos dans iPhoto, mais dans un dossier Photos de ma partition Media ; je ne reporte (momentanément) dans iPhoto que les photos sur lesquelles je veux travailler, pour les en retirer dès que c'est terminé.