Ответ.

История вопроса

Оптимизация размещения данных в памяти — ключевая особенность Rust, которая позволяет экономить ресурсы без потерь в безопасности кода. Enum Layout — это то, как компилятор размещает варианцы enum (с вариантами-структурами или примитивами), а также сами поля любой структуры. В других языках оптимизация такая часто скрыта, а в Rust очень важно учитывать порядок полей во избежание перерасхода памяти.

Проблема

Если порядок полей в структуре выбрать неудачно, то из-за особенностей выравнивания данных структура начнет "раздуваться" в размере. Для enum с ассоциированными данными ситуация усложняется — размер enum определяется наибольшим вариантом плюс размер дискриминатора. Пренебрежение этим приводит к избыточному потреблению памяти, снижению производительности кэша процессора.

Решение

Для эффективной упаковки структур и enum стоит располагать сначала наиболее «широкие» поля, затем более узкие, и учитывать паддинги, которые компилятор может добавить. Для enum — выбирать структуру вариантов так, чтобы они не стремились к максимальному размеру, если это не оправдано.

Пример кода:

struct BadAlign {
    a: u8,
    b: u32,
    c: u16,
}

struct GoodAlign {
    b: u32,
    c: u16,
    a: u8,
}

enum Packet {
    A(u8),
    B(u32, [u8; 10]),
}

Ключевые особенности:

• Размер структуры (и enum) зависит от порядка и типа полей.
• Enum с крупными вариантами делают весь enum крупнее, даже если другие варианты очень маленькие.
• Площадки выравнивания могут значительно увеличить расход памяти, особенно для массивов структур.

Вопросы с подвохом.

Можно ли сделать структуру меньше, просто поменяв порядок полей?

Да. Если поля идут в порядке снижения размера, то компилятор часто уменьшает количество паддингов, тем самым уменьшая общий размер структуры.

println!("{}", std::mem::size_of::<BadAlign>()); // например, 12
println!("{}", std::mem::size_of::<GoodAlign>()); // например, 8

Влияет ли какой-либо порядок полей на производительность доступа к ним?

Порядок сам по себе не влияет на скорость доступа через поля. Однако при последовательном переборе структуры на низком уровне (например, с SIMD-инструкциями или при работе с массивами структур в цикле) правильное выравнивание ускоряет доступ благодаря лучшему использованию кэша.

Если один вариант enum очень большой, будет ли каждый экземпляр enum занимать столько же памяти, даже если он других вариантов?

Да, размер enum всегда определяется максимальным из вариантов плюс дискриминатор. Любой Packet будет занимать размер B, даже если в нём A.

Типовые ошибки и анти-паттерны

• Игнорировать порядок полей, создавая лишний оверхед на выравнивание.
• Использовать enum с редкими, но огромными вариантами без обёрток или Box, раздувая память.
• Переупаковывать слишком агрессивно и жертвовать читабельностью ради пары байт.

Пример из жизни

** Негативный кейс

В структуре поля u8, потом u64. Использование в массиве из 100000 записей расходует до гигабайта памяти из-за паддингов.

Плюсы:

• Дешёвая реализация, просто "как получилось"

Минусы:

• Перерасход памяти, плохой locality

** Позитивный кейс

Структуры отсортировали по ширине полей, у enum крупные варианты вынесены в Box, мелкие оставлены in-place.

Плюсы:

• Меньше память, быстрее копирование, эффективнее работа процессора

Минусы:

• Чуть сложнее код, т.к. доступ Box требует распаковки