Antwort

In Rust versucht der Compiler, Daten effizient im Speicher zu platzieren, indem er Kenntnisse über Ausrichtung und Layout-Möglichkeiten von Strukturen und Enums nutzt. Die Frage ist besonders relevant in der Low-Level- und Systementwicklung, wenn die übermäßige Größe eines Typs zu erheblichen Speicherüberschüssen führt.

Hintergrund

Automatische Ausrichtung von Strukturen ist eine Eigenschaft der meisten Programmiersprachen, jedoch bietet der Rust-Compiler strenge Garantien über das Layout (wobei eine Optimierung desselben erlaubt ist) und realisiert bei Enums eine kompakte Speicherung, indem er den Speicher für alle Varianten zusammenführt und dabei die maximale Größe berücksichtigt).

Problem

Die Reihenfolge und Typen der Felder einer Struktur oder eines Enums beeinflussen die endgültige Größe des Typs aufgrund der Besonderheiten der Ausrichtung. Eine falsche Reihenfolge erhöht das "Padding" - ungenutzte Bytes. Bei Enums mit assoziierten Daten bestimmt die maximale Variante die Größe, und einige Konstruktionen können das Enum unerwartet groß machen.

Lösung

Es ist wichtig, die Reihenfolge der Felder korrekt anzugeben und die Typen auszuwählen, die Größe der Daten mithilfe von std::mem::size_of zu analysieren. Bei Enums sollte man vorsichtiger mit eingebetteten Strukturen und Zeigern umgehen.

Beispielcode:

struct Bad {
    a: u8,  // benötigt 1 Byte + 7 Bytes Padding
    b: u64, // benötigt 8 Bytes
}

struct Good {
    b: u64, // 8 Bytes, Ausrichtung von Beginn an
    a: u8,  // 1 Byte + 7 Bytes Padding am Ende
}

Größenüberprüfung:

use std::mem::size_of;
println!("{}", size_of::<Bad>());  // 16 Bytes
println!("{}", size_of::<Good>()); // 16 Bytes (aber Padding jetzt am Ende)

Für Enums:

enum Example {
    Unit,
    Num(u32),
    Pair(u64, u8),
}
println!("{}", size_of::<Example>()); // Größe — max(Größe der Varianten) + Discriminant

Wichtige Merkmale:

Reihenfolge der Felder und Ausrichtung sind entscheidend für das Speichermanagement
Für Enums wird die Größe durch die größte Variante plus Discriminant bestimmt
Eingebettete Strukturen und Enums innerhalb von Enums können die Größen aufblähen

Fragen mit Fallen.

Ändert sich die Größe der Struktur, wenn man die Felder u8 und u64 in der Struktur vertauscht?

Nein, die gesamte Größe wird weiterhin durch die Ausrichtung des größten Feldes bestimmt, aber das Padding verschiebt sich. Dies ist wichtig, wenn die Struktur in eine andere Struktur eingebunden oder an FFI übergeben wird.

Kann ein kleines Enum eine große Speichermenge haben?

Ja, wenn mindestens eine Variante ein großes Objekt oder einen Verweis enthält, hat die gesamte Größe des Enums die Größe der "schwersten" Variante plus Discriminant.

Ist das Layout einer Struktur immer auf allen Plattformen gleich?

Nein, Layout und Ausrichtung können zwischen Architekturen variieren. Für strikte Kontrolle wird das Attribut repr(C) verwendet.

#[repr(C)]
struct MyFFIStruct {
    x: u32,
    y: u8,
}

Typische Fehler und Anti-Pattern

Einfügen großer/nicht ausgerichteter Typen zwischen kleinen, die das Padding aufblähen
Blindes Einfügen von Enums mit großen eingebetteten Objekten
Fehlendes #[repr(C)] bei FFI

Beispiel aus dem Leben

Negativer Fall

In großen Sammlungen wird ein Enum mit einem eingebetteten Vec verwendet, der selten vorkommt, aber die Größe des Enums um das Zehnfache erhöht. Der Speicher wird verschwendet.

Vorteile:

Einfach umzusetzen; leicht Pattern Matching

Nachteile:

Hoher Speicherbedarf, Leistungseinbußen

Positiver Fall

Das Enum wird in mehrere kleinere Enums aufgeteilt, Arrays/Sammlungen werden separat gespeichert oder über Box für seltene Varianten verwaltet, das Layout wird über #[repr(C)] kontrolliert. Die Größe wird über size_of geprüft.