Swift utilise une optimisation de compilateur connue sous le nom d'utilisation des habitants supplémentaires (ou encapsulation des bits non utilisés) pour éliminer le surcoût de stockage du cas none de Optional. Pour les types de référence (classes, fermetures, AnyObject), la représentation du pointeur sous-jacent inclut une adresse nulle (0x0) qui n'est pas une référence d'objet valide ; Swift réutilise ce pointeur nul pour représenter Optional.none, tandis que tous les pointeurs non nuls représentent Optional.some. Lorsqu'on étend cela aux énumérations générales avec plusieurs cas contenant des charges utiles, le compilateur analyse les motifs de bits de tous les types de valeurs associés pour identifier les valeurs inutilisées communes (bits non utilisés). Si tous les types de charges utiles partagent au moins un nombre suffisant de bits non utilisés pour encoder le nombre de cas, l'énumération stocke le discriminateur de cas dans ces bits ; sinon, elle ajoute un octet ou un mot de balise séparé.
Lors de l'architecture du graphe de scène pour un moteur de rendu 3D en temps réel, l'équipe a dû stocker des références de parents optionnels pour 2 millions de nœuds de scène. Chaque nœud était une instance de classe, et la hiérarchie nécessitait Optional<Node> pour représenter les nœuds racines (qui n'ont pas de parent).
Solution A : Tableau booléen parallèle.
L'équipe a envisagé de maintenir un ContiguousArray<Bool> séparé aux côtés de ContiguousArray<Node> pour indiquer la présence des parents.
Avantages : Contrôle explicite, modèle indépendant du langage.
Inconvénients : La localité de cache est détruite par l'accès à deux régions mémoires disjointes ; le surcoût mémoire augmente de 2 Mo (1 octet par booléen, aligné) ; complexité de synchronisation lors de la restructuration de l'arbre.
Solution B : Modèle de nœud sentinelle.
Utiliser une instance de singleton global "nœud nul" pour représenter des parents absents.
Avantages : Stockage d'un seul pointeur, aucun surcoût optionnel.
Inconvénients : Violation de la sécurité des types ; le compilateur ne peut pas empêcher les opérations accidentelles sur le sentinelle ; nécessite des vérifications défensives dans l'ensemble de la base de code ; introduit des cycles de référence si le sentinelle détient des références vers de vrais nœuds.
Solution C : Optional Swift natif.
Adoption de Optional<Node> directement dans la structure de nœud.
Avantages : Sécurité complète à la compilation, syntaxe idiomatique Swift, aucun surcoût mémoire car le Optional utilise la représentation du pointeur nul pour none.
Inconvénients : Nécessite de comprendre que cette optimisation s'applique spécifiquement aux types de référence ; les types de valeur comme Int encourraient un remplissage.
L'équipe a choisi Solution C. Comme Node était une classe, l'enveloppe Optional n'ajoutait aucun octet à la taille de l'instance. Le résultat était une réduction de mémoire d'environ 16 Mo par rapport à l'approche booléenne parallèle (éliminant à la fois le stockage booléen et le remplissage d'alignement associé), tout en obtenant des garanties à la compilation qui ont éliminé une classe entière de plantages dus à des déréférencements nuls lors des refactorisations ultérieures.
Pourquoi Optional<Int> occupe-t-il généralement plus de mémoire qu'un Int, tandis que Optional<AnyObject> occupe le même espace qu'un AnyObject ?
Int est un entier en complément à deux de 64 bits utilisant tous les modèles de bits possibles pour représenter sa gamme numérique (-2^63 à 2^63-1), laissant aucun modèle de bits invalide (habitants supplémentaires) disponible pour le discriminant Optional. Par conséquent, le compilateur doit ajouter un octet séparé (ou un mot, en raison de l'alignement) pour stocker si l'option est some ou none. En revanche, AnyObject (et toutes les références de classe) sont des pointeurs où le modèle de bits tous zéros (nul) est garanti invalide en tant qu'adresse d'objet ; Optional revendique cette représentation nulle pour son cas none, nécessitant zéro ajout de stockage.
Combien de représentations distinctes au niveau de la machine existent pour "absence" dans Optional<Optional<T>> lorsque T est une classe, et pourquoi cela importe-t-il pour l'égalité ?
Il existe deux représentations distinctes : le .none extérieur (un pointeur nul au niveau extérieur) et .some(.none) (un pointeur extérieur valide pointant vers un nul interne). Comme le Optional interne consomme déjà la valeur du pointeur nul pour représenter sa propre vacuité, le Optional extérieur ne peut pas distinguer son propre none d'un .some contenant un none interne en utilisant uniquement la valeur du pointeur. Par conséquent, la couche extérieure nécessite un bit de balise séparé, et les deux états conceptuels "nil" ne sont pas égaux (Optional(Optional.none) != Optional.none). Cette distinction est cruciale lors du passage d'optionnels imbriqués retournés par des API génériques ou le décodage de JSON où les clés manquantes produisent des nuls extérieurs et les valeurs nulles produisent des nuls internes.
Lorsque vous définissez une énumération avec plusieurs cas de charge utile, comme case integer(Int), case boolean(Bool), qu'est-ce qui détermine si le compilateur stocke un octet de balise séparé ou intègre le discriminateur de cas dans la charge utile ?
Le compilateur effectue une analyse des bits non utilisés sur les types de valeurs associés. Bool n'utilise que le bit le moins significatif, laissant 7 bits inutilisés. Si tous les types de charges utiles fournissent des bits non utilisés suffisants pour identifier chaque cas de manière unique (par exemple, plusieurs références de classe partageant l'habitant supplémentaire nul), l'énumération pourrait empaqueter l'index de cas dans ces bits inutilisés. Cependant, Int et Bool ont des motifs de bits non utilisés disjoints (Int n'en a pas), obligeant le compilateur à allouer un octet de balise séparé (ou un mot) pour distinguer integer de boolean, augmentant la taille de l'énumération au-delà de la taille maximale de charge utile.