Ajouter à une liste de lecture
Continuons cette série sur les codes fantastiques avec une histoire d’occupation mémoire
Le compilateur Clang charge lors de son utilisation un tableau de structure contenant la description des différents intrinsèques qu’il supporte. Dans la version 15.0.x de ce dernier, chaque élément de ce tableau a le type suivant (quelques adaptations ont été faites pour faciliter la lecture, mais l’idée de base reste valable) :
Sur une machine 64 bits, sizeof(LanguageID) sera typiquement de 4 (une enum loge dans un int) et sizeof(Info) sera de 48 octets : 8 x 5 pour chaque pointeur, et 8 pour Langs (4 pour la valeur et 4 pour conserver l’alignement du champ suivant).
Perdre 4 octets par élément, pour un tableau qui en contient un bon millier, ce n’est pas rien. Comment faire pour améliorer la situation ? On peut commencer par échanger les places de Langs et Features. En opérant ainsi, on peut espérer avoir une structure compacte en mémoire, de 44 octets. Malheureusement, ce changement n’est pas suffisant : afin de conserver une structure dont la taille est un multiple de 8 (et ainsi faciliter le chargement de l’élément suivant), le compilateur va ajouter 4 octets de padding (rembourrage ?) en fin de structure.
On peut cependant forcer le comportement du compilateur en utilisant l’attribut packed :
La structure ainsi déclarée ne prend alors plus que 44 octets, mais le chargement d’un de ces champs peut alors se faire de manière non alignée, ce qui peut demander deux chargements mémoires au lieu d’un suivant l’architecture cible (ce n’est pas le cas sur x86_64).
Si l’on veut éviter d’utiliser un attribut qui, bien que supporté par GCC et Clang, n’est pas standard, on peut pousser le vice un peu plus loin en utilisant quelques connaissances métiers : l’ensemble des intrinsèques à modéliser est connu à la compilation, et n’est pas modifié à l’exécution. Or, il se trouve qu’il n’existe qu’une trentaine de valeurs utilisées pour le champ HeaderName. Faisons-en une énumération ! Elle sera stockée naturellement sur 4 octets, et on obtient alors (après réorganisation de ces champs) une structure de 40 octets sans avoir recours à une extension :
C’est l’approche qui a été choisie pour Clang dans sa version de développement.
Petit extra : il est possible depuis C++11 de choisir la taille de l’entier utilisé pour stocker une enum. Dans notre cas, enum HeaderID : uint16_t { ...}; combiné à la même approche pour LanguageID et l’attribut packed permettraient d’atteindre une structure de 36 octets, soit une réduction de 25 % de sa taille !
