Historique de la question.
Avant C++11, de nombreuses implémentations de std::string utilisaient le comptage de références (Copy-on-Write) pour partager les données de chaîne entre les instances, réduisant ainsi l'empreinte mémoire pour les copies. Cependant, cette approche posait des problèmes de sécurité des threads où des lectures simultanées pouvaient entraîner l'invalidation d'itérateurs ou de références lorsque le compteur de références interne était modifié. C++11 a explicitement interdit cette optimisation en exigeant que les fonctions membres const ne invalident pas les références ou les itérateurs, nécessitant une nouvelle stratégie d'optimisation pour atténuer le coût de performance de l'allocation sur le tas pour de courtes chaînes.
Le problème.
L'allocation sur le tas est coûteuse en raison des frais de synchronisation dans les allocateurs et des problèmes de localité de cache. Pour les applications traitant des milliards de courtes chaînes, telles que les analyseurs JSON ou les gestionnaires de protocoles réseau, l'allocation de mémoire pour des séquences de 5 à 15 caractères domine le temps d'exécution. Le défi consiste à stocker de courtes chaînes dans l'objet std::string lui-même — typiquement limité à 32 octets sur les systèmes 64 bits — sans briser la compatibilité ABI ou violer les fortes garanties de sécurité d'exception requises par la norme.
La solution.
Les implémentations utilisent généralement une union de trois membres pour le tampon de stockage : char* ptr_ pour le tableau alloué sur le tas, size_t capacity_, et char local_buffer_[N] pour le tableau embarqué. Un discriminateur, souvent encodé dans le bit de poids faible du membre size_ ou utilisant une valeur de capacité spécifique, détermine si la chaîne est en "mode SSO" ou "mode tas". Lorsque size() < SSO_CAPACITY, les caractères sont stockés dans local_buffer_, avec un terminator nul à local_buffer_[size()], évitant ainsi totalement l'allocation sur le tas. Pour les chaînes plus grandes, ptr_ pointe vers la mémoire du tas, et local_buffer_ est réutilisé pour stocker des métadonnées de capacité ou reste inutilisé.
// Implémentation conceptuelle (simplifiée) class string { union { struct { char* ptr; size_t size; size_t cap; } tas; // Actif lorsque cap >= SSO_CAP struct { char buffer[15]; // 15 caractères + terminator nul unsigned char size; // Métadonnées compactées, MSB indique le tas } sso; // Actif lorsque size < 15 } data; bool is_sso() const { return (data.sso.size & 0x80) == 0; } };
Considérez une application de trading à haute fréquence traitant des messages de protocole FIX contenant de nombreuses petites étiquettes (par exemple, "35=D", "150=2"). L'implémentation initiale utilisait std::string pour stocker chaque valeur d'étiquette, entraînant des millions d'allocations sur le tas par seconde et une sévère contention d'allocateurs qui bloquait le flux de données de marché.
Solution A : Pointeurs bruts dans le tampon. Utiliser des pointeurs char* dans le tampon d'origine offre zéro coût d'allocation et des performances maximales. Cependant, cette approche soulève des problèmes dangereux de gestion de durée de vie ; si le tampon d'origine est réutilisé ou libéré alors que les données de chaîne sont encore nécessaires, cela entraîne des bogues d'utilisation après libération. De plus, cela nécessite un suivi manuel des longueurs de chaîne, ce qui augmente la complexité du code et le potentiel d'erreurs.
Solution B : Allocateur personnalisé avec pools de mémoire. Implémenter des pools de mémoire locaux aux threads réduit la contention des allocateurs en regroupant les allocations. Cependant, cela ajoute une complexité de modèle important ou nécessite des allocateurs polymorphes dans l'ensemble du code. Cela n'élimine pas non plus complètement le coût d'allocation, mais l'amortit simplement sur plusieurs chaînes.
Solution C : std::string_view et SSO. L'utilisation de std::string_view pour un traitement en lecture seule évite les copies, tout en s'appuyant sur le SSO automatique de std::string pour les valeurs stockées, fournissant une sécurité avec un minimum de frais. Le principal inconvénient est la chute de performance lorsque les chaînes dépassent le seuil SSO (15-22 caractères), déclenchant soudainement des allocations sur le tas coûteuses. De plus, le déplacement de petites chaînes copie les données plutôt que de transférer des pointeurs, ce qui peut surprendre les développeurs qui s'attendent à une sémantique de déplacement O(1).
L'équipe a choisi Solution C, en reformant le parseur pour utiliser std::string_view pour les références temporaires et std::string uniquement lorsque la persistance était requise. Cela a réduit les allocations sur le tas de 95 % pour les messages FIX typiques, augmentant le débit de 50 000 à 800 000 messages par seconde tout en maintenant la sécurité de la mémoire.
Pourquoi le déplacement d'une courte chaîne qui utilise SSO en interne effectue une copie de caractères plutôt qu'un transfert de pointeur, et comment cela affecte-t-il l'état de l'objet déplacé ?
En mode SSO, le tableau de caractères réside directement dans l'objet std::string (typiquement en tant que membre d'une union interne). Contrairement aux chaînes allouées sur le tas où le constructeur de déplacement transfère simplement le pointeur char* et annule la source, déplacer une chaîne SSO nécessite de copier les caractères du tampon interne de la source vers le tampon interne de la destination. Cela est nécessaire car l'objet source sera détruit, et son tampon interne avec lui ; la destination ne peut pas pointer vers la mémoire à l'intérieur de la source qui va bientôt être détruite. Par conséquent, déplacer une petite chaîne a une complexité O(N) plutôt que O(1), et l'objet déplacé reste dans un état valide mais non spécifié (pas vide), contenant toujours ses caractères d'origine jusqu'à sa destruction ou sa réaffectation.
Comment std::string maintient-elle l'exigence de C++11 selon laquelle c_str() et data() renvoient des tableaux de caractères terminés par un zéro lorsqu'elle fonctionne en mode SSO, étant donné que la taille du tampon interne est fixe ?
L'implémentation garantit que le tampon SSO est toujours un octet plus grand que la capacité maximale SSO (par exemple, 16 octets au total pour une chaîne de 15 caractères). Lorsqu'une chaîne de longueur N (où N < SSO_CAPACITY) est stockée, l'implémentation écrit le terminator nul à la position N dans le tampon local. Les méthodes data() et c_str() renvoient un pointeur vers le début de ce tampon local lorsqu'elles sont en mode SSO, plutôt que vers le pointeur du tas. Cela garantit la terminaison nulle sans allocation supplémentaire, satisfaisant les exigences de la norme selon lesquelles c_str() renvoie const char* vers une chaîne terminée par un zéro, et depuis C++11, que data() pointe également vers un tableau terminé par un zéro.
Pourquoi la capacity() d'un std::string vide peut-elle varier entre différentes implémentations de la bibliothèque standard (par exemple, 15 contre 22), et quelles implications ABI cela a-t-il pour le mélange des versions de la bibliothèque standard ?
La taille du tampon SSO est un détail d'implémentation (libc++ utilise généralement 22 caractères sur les systèmes 64 bits en exploitant l'alignement, tandis que libstdc++ utilise 15). Cette taille dépend de la manière dont l'implémentation empaquette les métadonnées de taille/capacité avec le tampon local dans la disposition de l'objet std::string (typiquement 32 octets au total). Étant donné que cela n'est pas standardisé, le mélange de binaires compilés avec différentes implémentations de bibliothèque standard (par exemple, passer un std::string d'une bibliothèque compilée avec GCC à une application compilée avec Clang) entraîne un comportement indéfini en raison de dispositions de mémoire incompatibles. Les candidats supposent souvent que std::string a une ABI standard, mais c'est l'un des types les moins portables à travers les frontières de bibliothèque.