Rust和C语言中的神奇内存优化

在编程中因为缺乏对内存布局的了解，我们就浪费了如此多的内存，这真是太令人抓狂了。

让我们回顾一下编程语言中一些基本类型的内存大小(以Rust为例)：

• bool : 1

• u8 : 1

• u16 : 2

• u32 : 4

• u64 : 8

• char : 4

struct Foo {    elem:  u32,    other: u16,
}

如果是6，就不会问你这个问题了。虽然6并不是完全不正确——因为结构体对于u32包含4个字节，对于u16包含2个字节——结构体的大小是通过对齐最大的字段并将总大小四舍五入到最接近的倍数来计算的。如果这不是很清楚，让我们看一个简单的表示。

struct Bar {    num:     u16,    bigger:  u32,    another: u16,
}

如果我们遵循前面描述的心智模型，Bar结构体的大小将是12。如果我们考虑结构体的字段的最大对齐，即4，并将所有其他字段的大小四舍五入为4，我们得到:4 4 4 = 12。

结果如下：(2 + 2) + 4 = 8。似乎我们通过重新排列结构体的字段优化了空闲空间，事实上，Rust编译器足够聪明，可以自动完成这项工作，但并不是所有强类型语言都是如此！让我们打印Rust结构体的内存大小，然后对C中的等效结构体做同样的事情：

std::mem::size_of::<Bar>() // output: 8

struct Bar {
    uint16_t num;
    uint32_t bigger;
    uint16_t another;};
sizeof(struct Bar) // output: 12

似乎Rust编译器优化了结构体，而C编译器没有！这是因为C程序员真的需要理解计算机是如何在底层(ABI)工作的，不像Rust程序员(只是开玩笑😳)…更严重的是，Rust编译器是高度优化的，并为你处理这些，但在C中简单的手动重新排列将达到相同的结果。

Rust编译器会高度优化你指示它优化的任务。这并不意味着在Rust中你可以忽略数据布局，理解和考虑数据布局仍然很重要。

下面是当前结构体数据布局的可视化表示：

struct Bar {
    uint32_t bigger;
    uint16_t num;
    uint16_t another;};
sizeof(struct Bar) // output: 8

enum HtmlTag {    H1,    H2,    UnorderedList,    OrderedList,    ...}
std::mem::size_of::<HtmlTag>() // output: 1

struct HtmlToken {    start_position: u32,    token_tag:      HtmlTag, }
std::mem::size_of::<HtmlToken>() // output: 8

该结构体的大小是8字节！u32为4字节，enum为1字节，填充为3字节。现在，假设我们对一个大型HTML网页进行标记，并生成10,000个标记。

在这种情况下，内存中总大小为10,000 * 8 = 80,000字节，其中填充30,000字节🥵。这是对内存的巨大浪费，而且这种情况比你想象的要频繁得多。

布尔值也有1字节的大小。例如，如果你有一个带有整数和布尔值的结构体，它可能会为该结构体的每个实例生成3个字节的填充。

struct HtmlTokens {
    start_positions: [u32; 1],
    token_tags:      [HtmlTag; 1], }
std::mem::size_of::<HtmlTokens>() // output: 5

总结