Risposta alla domanda.
Rust impiega una strategia di ottimizzazione del layout conosciuta come riempimento di valori di nicchia per eliminare l'overhead di memorizzazione degli discriminanti enum quando le varianti contengono tipi con pattern di bit non validi. Il compilatore identifica i valori "di nicchia" all'interno dell'intervallo rappresentabile di un tipo—come il valore zero per NonZeroU32 o il puntatore nullo per i riferimenti—e riutilizza questi pattern di bit per codificare altre varianti enum come None. Questa trasformazione si basa sul fatto che il tipo di payload possiede un intervallo di validità ristretto definito dalle sue proprietà intrinseche o dagli attributi interni rustc_layout. Affinché un tipo possa fungere da portatore di nicchia valido, deve presentare almeno un pattern di bit che costituisce un comportamento indefinito per essere costruito o letto, consentendo così al compilatore di riservare quel pattern per le varianti alternative dell'enum senza allocare spazio aggiuntivo per lo discriminante.
Situazione della vita reale
Durante lo sviluppo di un motore di trading ad alta frequenza, il nostro team ha riscontrato una grave pressione sulla cache quando memorizzava milioni di timestamp degli ordini in un Vec<Option<u64>>. Ogni timestamp opzionale consumava 16 byte a causa dell'allineamento e dell'overhead dello discriminante, nonostante i timestamp stessi fossero valori Unix epoch strettamente positivi. Avevamo urgente bisogno di ridurre l'impronta di memoria senza sacrificare la sicurezza o ricorrere a puntatori raw che avrebbero complicato le garanzie di Send e Sync necessarie per l'elaborazione interthread.
Un approccio considerato era il packing manuale dei bit usando valori u64 raw e valori zero sentinella con funzioni di conversione non sicure. Questa soluzione prometteva massima efficienza di memoria ma introduceva rischi catastrofici: un errore logico poteva costruire un NonZeroU64 non valido o dereferenziare un puntatore nullo mascherato da zero, violando gli invarianti di sicurezza della memoria di Rust. Inoltre, richiederebbe ampie tracce di audit e blocchi unsafe che il team cercava di evitare.
Un altro candidato prevedeva di utilizzare direttamente Optionstd::num::NonZeroU64, sfruttando l'ottimizzazione delle nicchie garantita dalla libreria standard. Questo approccio manteneva la piena sicurezza del tipo e le espressioni match ergonomiche, garantendo che l'Option occupasse esattamente 8 byte invece di 16. Il principale vincolo era che dovevamo garantire che i timestamp non fossero mai zero, il che era vero per la nostra logica di dominio poiché tutti i timestamp erano post-1970.
Abbiamo scelto la seconda soluzione, rifattorizzando il nostro nuovo tipo Timestamp per incapsulare NonZeroU64 e validando gli input al confine del sistema. Il risultato è stata una riduzione del 50% dell'uso di memoria per la nostra cache principale del libro degli ordini. Questa ottimizzazione ha eliminato il thrashing della cache e migliorato la latenza di ricerca del 30%, tutto ottenuto senza una sola riga di codice unsafe.
Cosa spesso i candidati dimenticano
Perché Option<u32> consuma 8 byte mentre Option<NonZeroU32> ne consuma solo 4, e come si comporta questa ottimizzazione con tipi annidati come Option<Option<NonZeroU32>>?
Il tipo u32 ammette tutti i 2^32 pattern di bit come validi, lasciando nessun pattern di bit "di riserva" che il compilatore possa riutilizzare come variante None. Di conseguenza, il compilatore deve aggiungere un byte discriminante (padded a 4 byte per allineamento), ottenendo un totale di 8 byte. Al contrario, NonZeroU32 dichiara esplicitamente che il pattern di bit 0x00000000 è non valido, creando una nicchia che Rust utilizza per codificare None, consentendo così all'Option di occupare esattamente 4 byte.
Per le strutture annidate, l'ottimizzazione si chaina efficacemente: Option<Option<NonZeroU32>> rimane 4 byte perché il Option esterno utilizza un diverso pattern di bit non valido (ad esempio, 0x00000001) dallo spazio di nicchia disponibile di NonZeroU32. Questa ottimizzazione ricorsiva continua a condizione che il tipo portatore possieda sufficienti pattern di bit non validi per ospitare tutti i valori discriminanti dell'enum.
Come interagiscono gli attributi di layout espliciti come #[repr(C)] o #[repr(u8)] con l'ottimizzazione delle nicchie, e perché questa interazione è importante per i confini FFI?
Quando si applicano #[repr(C)] o #[repr(u8)], il programmatore impone un layout di memoria fisso in cui lo discriminante occupa un offset specifico con una dimensione definita. Questa rappresentazione esplicita disabilita effettivamente l'ottimizzazione delle nicchie, garantendo la compatibilità ABI con le strutture C che si aspettano tag espliciti ma costringendo l'enum a consumare spazio aggiuntivo per lo discriminante.
Nei contesti FFI, questa distinzione si rivela critica perché il codice C si aspetta lo discriminante a un offset prevedibile e stabile. Passare un enum Rust ottimizzato per le nicchie privo di attributi repr espliciti attraverso il confine porta a comportamenti indefiniti, mentre #[repr(C)] garantisce stabilità del layout a costo della necessaria efficienza della memoria.
Cosa impedisce a MaybeUninit<T> di fungere da portatore di nicchia per l'ottimizzazione degli enum anche quando T stesso possiede pattern di bit non validi, come in Option<MaybeUninit<NonZeroU32>>?
MaybeUninit<T> è architettonicamente progettato per contenere qualsiasi pattern di bit senza invocare comportamenti indefiniti, poiché il suo obiettivo è rappresentare una memoria potenzialmente non inizializzata. Di conseguenza, il compilatore tratta MaybeUninit<T> come privo di pattern di bit non validi, il che significa che il suo intervallo di validità comprende tutte le 2^(8*sizeof(T)) possibili combinazioni di bit. Questa validità totale elimina eventuali nicchie disponibili che potrebbero essere riutilizzate per l'ottimizzazione degli enum, indipendentemente dalle proprietà di T.
Pertanto, Option<MaybeUninit<NonZeroU32>> occupa 8 byte—la dimensione di MaybeUninit<u32> più il padding dello discriminante—nonostante il sottostante NonZeroU32 abbia una validità ristretta. Questo comportamento illustra che l'ottimizzazione delle nicchie funziona esclusivamente sui vincoli di validità del tipo immediato piuttosto che sulle proprietà transitive dei suoi contenuti potenziali.