Améliorer l’utilisation de la mémoire et les performances avec Swift

Découvrez comment optimiser les performances des apps et bibliothèques Swift à l’aide de Swift 6.2. Les nouveaux types InlineArray et Span réduisent les allocations, les vérifications d’exclusivité et le comptage de références. Une nouvelle bibliothèque Swift open source, Binary Parsing, est introduite pour une analyse binaire rapide et sécurisée.

L’app de cette session WWDC25 charge les images au format QOI, un format simple et sans perte, avec une spécification d’une seule page. L’analyseur d’images de l’app prend en charge diverses méthodes d’encodage des pixels. Ensuite, l’app charge instantanément un petit fichier d’icône, mais il faut quelques secondes pour charger une photo plus grande d’un oiseau.

Lorsque les apps fonctionnent avec des données réelles, une utilisation incorrecte des algorithmes ou des structures de données peut nuire aux performances. Pour identifier ces problèmes et y remédier, vous pouvez utiliser Instruments, qui fournit des modèles d’instruments destinés à l’analyse des allocations et des versions, et qui permet d’identifier le code inefficace à l’aide de profileurs. L’instrument Time Profiler est particulièrement utile pour remédier aux problèmes de performances. En analysant les appels capturés et les traces de pile, vous pouvez identifier les zones où les apps passent le plus de temps. Dans l’exemple, un temps considérable a été consacré à platform_memmove, un appel système pour la copie de données. À l’aide d’Instruments, cet exemple analyse une méthode personnalisée nommée readByte. Cette méthode a été ajoutée à une extension du type Data, ce qui entraînait une copie excessive des données binaires. Dans l’exemple, la méthode est remplacée par la méthode popFirst(), plus efficace, qui réduit les données à partir du début d’une séquence sans les copier. Cette modification a résolu le problème de performances dans la méthode readByte. Après avoir effectué la modification, le profil a été exécuté à nouveau et la barre platform_memmove, qui occupait une place conséquente, a disparu du flamegraph. Les tests comparatifs ont révélé une accélération considérable, et la relation entre la taille de l’image et le temps d’analyse est passée de quadratique à linéaire, ce qui indique un algorithme plus efficace.

L’app est à nouveau profilée et il s’avère que l’analyseur d’images entraîne des allocations et des désallocations de mémoire excessives, en particulier au niveau des tableaux. Le nombre élevé d’allocations, près d’un million pour l’analyse d’une seule image, indique un problème critique. La plupart de ces allocations sont temporaires et de courte durée, ce qui suggère qu’elles peuvent être optimisées. Pour identifier la source de ces allocations inutiles, l’exemple utilise l’instrument Allocations dans Instruments. L’analyse révèle qu’une méthode appelée RGBAPixel.data(channels:) est en grande partie à l’origine du problème. Cette méthode crée un tableau chaque fois qu’elle est appelée, ce qui entraîne un nombre important d’allocations. La structure du code, qui implique une chaîne complexe de méthodes flatMap et prefix, contribue au problème. Chaque étape de cette chaîne entraîne de nouvelles allocations, car les tableaux sont créés, aplatis et copiés à plusieurs reprises. Bien que cette approche soit concise, elle n’est pas efficace en termes de mémoire. Pour résoudre ce problème, l’exemple réécrit la fonction d’analyse. Au lieu de s’appuyer sur des allocations intermédiaires, il calcule à l’avance la taille totale des données résultantes et alloue un seul tampon. Cette approche élimine la nécessité d’allocations répétées pendant le processus de décodage.

Les performances de l’app se sont tellement améliorées que les outils de profilage ont eu besoin de plus de données. Après avoir répété le code d’analyse 50 fois, les résultats ont affiché les symboles swift_beginAccess et swift_endAccess, qui indiquent des tests d’exclusivité. Ces tests d’exclusivité ont été provoqués par des propriétés de la classe State imbriquées dans la structure QOIParser, que l’exemple déplace ensuite directement dans le type d’analyseur parent afin d’éliminer les vérifications d’exclusivité. Après quelques ajustements du compilateur, la vérification de l’exclusivité a été entièrement supprimée, comme l’a confirmé un nouveau profil.

Cet exemple remplace l’utilisation d’Array dans l’app par InlineArray, une collection de taille fixe stockée et intégrée, qui optimise l’utilisation de la mémoire en éliminant le comptage de références et les vérifications d’exclusivité. Cette méthode est idéale pour le cache de pixels, un tableau de 64 éléments dont la taille ne change jamais et qui est modifié sur place, car cela améliore les performances sans nécessiter de copie ou de partage de références.

Dans l’exemple d’optimisation finale de l’app, les nouveaux types Span sont utilisés pour optimiser les performances et renforcer la sécurité de la mémoire. Dans Instruments, le flamegraph est utilisé à partir de l’analyse Time Profiler. Les données profilées se concentrent sur le QOIParser et permettent d’identifier qu’un temps significatif est consacré aux opérations de comptage de références, en particulier avec le type Data, en raison de sa sémantique de copie à l’écriture. Span et ses types associés constituent une nouvelle façon de travailler avec la mémoire contiguë dans une collection. Ils utilisent la fonctionnalité non échappable (~Escapable) de Swift, qui lie leur durée de vie à la collection, garantissant ainsi la sécurité de la mémoire et éliminant la nécessité d’une gestion manuelle de la mémoire. Cela permet un accès efficace à la mémoire sans les risques associés aux pointeurs non sécurisés. L’exemple montre comment utiliser les types Span pour réécrire des méthodes existantes, afin de les rendre plus simples, plus sécurisées et plus performantes. Dans les méthodes d’analyse d’images, Data est remplacé par RawSpan, ce qui réduit considérablement la surcharge liée au comptage de références. De plus, OutputSpan est adopté dans le processus d’analyse pour plus d’efficacité, ce qui rend l’opération d’analyse six fois plus rapide qu’auparavant sans avoir recours à des pointeurs non sécurisés.

Swift Binary Parsing vous permet de créer des analyseurs syntaxiques sûrs et efficaces pour les formats binaires. Il offre des outils pour gérer divers aspects liés à la sécurité, notamment la prévention des dépassements d’entier, la spécification du signe, de la largeur de bit et de l’ordre des octets, ainsi que la validation des types personnalisés. La bibliothèque est déjà utilisée chez Apple et est accessible publiquement. Vous pouvez l’essayer et y contribuer via les forums Swift et GitHub.

Les principaux points à retenir sont les suivants : Utilisation de Xcode et Instruments pour le profilage des apps. Analyse des performances des algorithmes afin d’identifier les goulots d’étranglement. Exploration de solutions aux problèmes susmentionnés avec les nouveaux types InlineArray et Span introduits dans Swift 6.2.