Storia della domanda.
Prima di C++11, molte implementazioni di std::string utilizzavano il conteggio dei riferimenti (Copy-on-Write) per condividere i dati delle stringhe tra le istanze, riducendo l'impronta di memoria per le copie. Tuttavia, questo approccio ha causato problemi di sicurezza dei thread, in cui letture simultanee potevano innescare l'invalidazione di iteratori o riferimenti quando il conteggio dei riferimenti interno veniva modificato. C++11 ha esplicitamente vietato questa ottimizzazione richiedendo che le funzioni membro const non invalidassero riferimenti o iteratori, necessitando una nuova strategia di ottimizzazione per mitigare il costo delle allocazioni heap per stringhe corte.
Il Problema.
L'allocazione heap è costosa a causa del sovraccarico di sincronizzazione negli allocatori e dei problemi di località della cache. Per applicazioni che elaborano miliardi di piccole stringhe, come parser JSON o gestori di protocolli di rete, allocare memoria per sequenze di 5-15 caratteri domina il tempo di esecuzione. La sfida consiste nel memorizzare piccole stringhe all'interno dell'oggetto std::string stesso—tipicamente limitato a 32 byte su sistemi a 64 bit—senza compromettere la compatibilità ABI o violare le forti garanzie di sicurezza delle eccezioni richieste dallo standard.
La Soluzione.
Le implementazioni utilizzano tipicamente un'unione di tre membri per il buffer di memorizzazione: char* ptr_ per l'array allocato in heap, size_t capacity_, e char local_buffer_[N] per l'array incorporato. Un discriminante, spesso codificato nel bit meno significativo del membro size_ o utilizzando un valore di capacità specifico, determina se la stringa è in "modalità SSO" o "modalità heap". Quando size() < SSO_CAPACITY, i caratteri sono memorizzati in local_buffer_, con un terminatore nullo in local_buffer_[size()], evitando completamente l'allocazione heap. Per stringhe più grandi, ptr_ punta alla memoria heap, e local_buffer_ viene riutilizzato per memorizzare i metadati della capacità o rimane inutilizzato.
// Implementazione concettuale (semplificata) class string { union { struct { char* ptr; size_t size; size_t cap; } heap; // Attivo quando cap >= SSO_CAP struct { char buffer[15]; // 15 caratteri + terminatore nullo unsigned char size; // Metadati impacchettati, MSB indica heap } sso; // Attivo quando size < 15 } data; bool is_sso() const { return (data.sso.size & 0x80) == 0; } };
Considera un'applicazione di trading ad alta frequenza che elabora messaggi del protocollo FIX contenenti numerosi piccoli tag (ad esempio, "35=D", "150=2"). L'implementazione iniziale utilizzava std::string per memorizzare ciascun valore del tag, risultando in milioni di allocazioni heap al secondo e una grave contesa degli allocatori che limitava il feed di dati di mercato.
Soluzione A: Puntatori raw nel buffer. Utilizzare puntatori char* nel buffer originale offre un sovraccarico di allocazione pari a zero e prestazioni massime. Tuttavia, questo approccio introduce preoccupazioni per la gestione della durata pericolose; se il buffer originale viene riutilizzato o deallocato mentre i dati della stringa sono ancora necessari, si traduce in bug di uso dopo la liberazione. Inoltre, richiede il tracciamento manuale delle lunghezze delle stringhe, aumentando la complessità del codice e il potenziale di errore.
Soluzione B: Allocatore personalizzato con pool di memoria. Implementare pool di memoria locali ai thread riduce la contesa degli allocatori raggruppando le allocazioni. Tuttavia, ciò aggiunge una complessità significativa ai template o richiede allocatori polimorfici in tutto il codice sorgente. Non elimina nemmeno completamente il sovraccarico di allocazione, riducendo solo i costi su più stringhe.
Soluzione C: std::string_view e SSO. Utilizzare std::string_view per l'elaborazione in sola lettura evita copie, mentre fare affidamento su SSO automatico di std::string per valori memorizzati fornisce sicurezza con un sovraccarico minimo. L'inconveniente principale è il cliff delle prestazioni quando le stringhe superano la soglia SSO (15-22 caratteri), attivando improvvisamente allocazioni heap costose. Inoltre, spostare piccole stringhe copia i dati anziché trasferire i puntatori, il che può sorprendere gli sviluppatori che si aspettano semantiche di spostamento O(1).
Il team ha scelto Soluzione C, ristrutturando il parser per utilizzare std::string_view per riferimenti temporanei e std::string solo quando era necessaria la persistenza. Ciò ha ridotto le allocazioni heap del 95% per i messaggi FIX tipici, migliorando il throughput da 50.000 a 800.000 messaggi al secondo mantenendo la sicurezza della memoria.
Perché spostare una corta stringa che utilizza SSO internamente esegue una copia dei caratteri piuttosto che un trasferimento del puntatore, e come ciò influisce sullo stato dell'oggetto spostato?
In modalità SSO, l'array di caratteri risiede direttamente all'interno dell'oggetto std::string (tipicamente come membro di un'unione interna). A differenza delle stringhe allocate in heap dove il costruttore di spostamento trasferisce semplicemente il puntatore char* e azzera la sorgente, spostare una stringa SSO richiede di copiare i caratteri dal buffer interno della sorgente al buffer interno della destinazione. Questo è necessario perché l'oggetto sorgente verrà distrutto, e il suo buffer interno insieme; la destinazione non può puntare alla memoria all'interno della sorgente che sta per essere distrutta. Di conseguenza, spostare una piccola stringa ha complessità O(N) anziché O(1), e l'oggetto spostato rimane in uno stato valido ma non specificato (non vuoto), contenendo ancora i suoi caratteri originali fino alla distruzione o alla riassegnazione.
Come fa std::string a mantenere il requisito C++11 che c_str() e data() restituiscono array di caratteri terminati da null quando operano in modalità SSO, data la dimensione fissa del buffer interno?
L'implementazione garantisce che il buffer SSO sia sempre un byte più grande della massima capacità SSO (ad esempio, 16 byte totali per una stringa di 15 caratteri). Quando si memorizza una stringa di lunghezza N (dove N < SSO_CAPACITY), l'implementazione scrive il terminatore nullo nella posizione N nel buffer locale. I metodi data() e c_str() restituiscono un puntatore all'inizio di questo buffer locale quando in modalità SSO, piuttosto che il puntatore heap. Ciò garantisce la terminazione nulla senza allocazione aggiuntiva, soddisfacendo i requisiti dello standard che c_str() restituisce const char* a una stringa terminata da null, e poiché C++11, che data() punti anche a un array terminato da null.
Perché la capacity() di una std::string vuota può variare tra diverse implementazioni della libreria standard (ad esempio, 15 contro 22) e quali sono le implicazioni ABI per la miscelazione delle versioni della libreria standard?
La dimensione del buffer SSO è un dettaglio di implementazione (libc++ utilizza tipicamente 22 caratteri su sistemi a 64 bit sfruttando l'allineamento, mentre libstdc++ utilizza 15). Questa dimensione dipende da come l'implementazione impacchetta i metadati di dimensione/capacità insieme al buffer locale all'interno del layout dell'oggetto std::string (tipicamente 32 byte totali). Poiché questo non è standardizzato, mescolare binari compilati con diverse implementazioni della libreria standard (ad esempio, passando un std::string da una libreria compilata con GCC a un'applicazione compilata con Clang) risulta in un comportamento indefinito a causa di layout di memoria incompatibili. I candidati spesso presumono che std::string abbia un ABI standard, ma è uno dei tipi meno portabili attraverso i confini delle librerie.